This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |