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] |
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?
Index: config.h =================================================================== RCS file: /cvs/src/src/newlib/libc/include/sys/config.h,v retrieving revision 1.39 diff -u -r1.39 config.h --- config.h 13 May 2003 09:46:48 -0000 1.39 +++ config.h 28 Apr 2004 20:45:14 -0000 @@ -20,6 +20,14 @@ #define UINT_MAX 65535 #endif +#if (defined(__arm__) || defined(__thumb__)) +#ifdef __ARMEL__ +#define BYTE_ORDER 1234 +#else +#define BYTE_ORDER 4321 +#endif +#endif + #if defined (__H8300__) || defined (__H8300H__) || defined(__H8300S__) #define __SMALL_BITFIELDS #define H8300 1
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |