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 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?
Ralf