TITLE: detecting endianism (Newsgroups: comp.std.c++, 24 Feb 97) BACHE: Alex Bache >I think it would be nice to have some sort of way of determining at >compile time if the machine stores numbers internally as big or little >endian numbers. ... >There are cases where you need to know this, in order to write portable >code. Sure, you can write a function to work it out, but you can't >determine it at compile time. CLAMAGE: Stephen.Clamage@Eng.Sun.COM (Steve Clamage) The suggestion assumes that numbers are either big-endian or little- endian. That is not a requirement. I once used a system where 4-byte integers were stored not as 1-2-3-4 or 4-3-2-1, but as 2-1-4-3. Also, some floating-point on the VAX stores the most-significant byte near the middle of the storage allocated for it, much like those funny integers. Once loaded into registers, the bytes get straightened out -- load/store always does the right thing, as does arithmetic, whether in registers or directly in memory. You only get into trouble when accessing individual bytes directly in memory, in effect casting from int* or double* to char*. The relationship between the address order of bytes in memory and the significance of the bytes is not limited to two possibilities. Add to this the fact that it is common for bytes to be 9, 32, or 36 bits. I think that finding a way to give you all the information you really need in the high-level language is not going to succeed. The alternatives would seem to be 1. status quo -- you are on your own; 2. restrict C++ to platforms with "nice" characteristics (as Java does); 3. provide language support for only part of the job. Actually #3 is also status quo, but we could argue about how much additional support is appropriate. I suppose we could add something that described byte order as one of "big-endian, little-endian, neither". Hmmm. What if short, int, and long did not all have the same endianness? In my example above, shorts were "little-endian" but longs were "neither". Should we include floating-point in the endianness specification? VAX integers are all "little-endian", but floating-point varies -- floats are "little-endian", doubles are "neither", if I remember correctly. Having "neither" as a possibility means that portable code will still have to use other means if "neither" is true. It seems to me the endianness addition doesn't buy very much.