__IEEE_*_ENDIAN vs. BYTE_ORDER

[Jeff Johnston]

Ralf Corsepius wrote:
> On Wed, 2004-04-28 at 23:21, 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
> 
> Sorry, typo: s,sys/endian.h,machine/endian.h,
> 
> 
>>in sys/params.h, similar to the way BSD handles this issue?
> 

I went back and took another look at this.  Actually, sys/param.h is already 
being overridden when necessary by various platforms.  The ARM is one of these 
and you will see a special sys/param.h in the libc/sys/arm directory.  In this 
file, a check is made for __ARMEB__ rather than the default above.

-- Jeff J.