__IEEE_*_ENDIAN vs. BYTE_ORDER

[Jeff Johnston]

Ralf Corsepius wrote:
> On Wed, 2004-04-28 at 22:45, Jeff Johnston wrote:
> 
>>Ralf Corsepius wrote:
>>
>>>Hi,
>>>
>>>Newlib's sys/param.h applies __IEEE_*_ENDIAN (from machine/ieeefp.h) to
>>>define BYTE_ORDER.
>>>
>>>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 __IEEE_BIG_ENDIAN
>>>#define BYTE_ORDER BIG_ENDIAN
>>>
>>>even for little endian arm targets, while I think
>>>#define __IEEE_BIG_ENDIAN
>>>#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.