__IEEE_*_ENDIAN vs. BYTE_ORDER
Thu Apr 29 06:34:00 GMT 2004
Ralf Corsepius wrote:
> On Wed, 2004-04-28 at 22:45, Jeff Johnston wrote:
>>Ralf Corsepius wrote:
>>>Newlib's sys/param.h applies __IEEE_*_ENDIAN (from machine/ieeefp.h) to
>>>AFAIU, __IEEE_*_ENDIAN denotes the floating point endianess, only, which
>>>doesn't necessarily match with a CPU's general endianess.
>>>E.g. some arm-CPUs seem to use __IEEE_BIG_ENDIAN, while actually being
>>>little endian targets.
>>>On these targets newlib's sys/param.h results into
>>>#define BYTE_ORDER BIG_ENDIAN
>>>even for little endian arm targets, while I think
>>>#define BYTE_ORDER LITTLE_ENDIAN
>>>would have been correct.
>>>I.e. I suspect newlib's sys/param.h to be "illegally" using
>>>__IEEE_*_ENDIAN to setup BYTE_ORDER. I am wrong or right?
>>Newlib's sys/param.h is simply defaulting. Note that it checks to see if
>>BYTE_ORDER is already defined. In special cases such as the ARM where the byte
>>order and the floating-point byte order don't match up, the sys/config.h file
>>should have defined the BYTE_ORDER as appropriate.
>>I believe the attached patch should do the trick.
> Thanks, I see how this works.
> However, wouldn't it be cleaner to separate BYTE_ORDER from
> __IEEE_*_ENDIAN, to implement a sys/endian.h header and use this header
> in sys/params.h, similar to the way BSD handles this issue?
Well, that would introduce yet another header file to edit when introducing a
new port and that header file isn't part of any of the standards we generally
attempt to adhere to (ANSI, C99, Single Unix, POSIX, EL/IX, glibc). IMO, I find
it cleaner simply to keep such configuration info restricted to sys/config.h.
-- Jeff J.
More information about the Newlib