This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: __IEEE_*_ENDIAN vs. BYTE_ORDER
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