Re: __IEEE_*_ENDIAN vs. BYTE_ORDER

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

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?

Ralf