WM> Wow, one's complement... I have to admit, that's something I never
 WM> considered. Now that you mention it, I think I can probably go on ignoring
 WM> it. ;-) But you do have me thinking about how I'd 
 WM> implement those functions
 WM> in a compatible way...

With standardization, most systems are now based on two's complemnt, 8 bit
bytes / character size, etc....  So, yes, there are a number of things that
can be ignored now....

 WM> BTW, does Max often store negative numbers on disk? I would expect that to
 WM> come up seldom, if ever.

I believe it is rare.  Zero, -1, or max unsigned int, I believe is used in
some spots for unlimited values.                       

 BJ> integer data can easily be handled as you suggest, maybe even with a 
 BJ> union on the structures.....

 WM> A union kind of negates the purpose of avoiding the
"packed" attribute. 
 WM> (Not that that was the only purpose, but still.)  

I guess I haven't commented on my differinciation between the routines to
read / write the data and the actual usage of the data....  

 WM> IMHO there is really little point in retaining the old methods; it just
 WM> makes the code more complicated (with the big-endian side likely to end up
 WM> less well-maintained), for very very little performance gain. (If you want
 WM> to maintain dual versions of the structure definitions for the benefit of
 WM> third-party programmers -- as in bluewave.h -- that's another story; you
 WM> can do that easily. But I see no benefit to having dual access methods
 WM> within the Maximus code itself.)

Part of my thoughts is that the code that is concerned with this is burried
in a common access method used by the rest of the program.  Only one spot
needs to be concerned with the changes....    Basically like private
methods to deal with the endian issues, etc.

Any way....  Take care.....

Bob Jones, 1:343/41


--- Maximus/UNIX 3.03b