This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

Re: [Patch] Fix MIPS build failure caused by -Werror=undef


On Tue, 2015-02-17 at 19:58 +0000, Maciej W. Rozycki wrote:

>  There's clearly nothing Linux specific there although one might ask which 
> of the two of __MIPSEB vs __MIPSEB__ is the "traditional" macro we might 
> want to keep.  Or maybe _MIPSEB even.  I'm not sure offhand and clearly 
> current GCC defines all at a time.
> 
>  Also I wonder if sanity checks like:
> 
> #if defined (__MIPSEB) && defined (__MIPSEL)
> # error "Both __MIPSEB and __MIPSEL, endianness configuration problem?"
> #elif defined (__MIPSEB)
> # define __BYTE_ORDER __BIG_ENDIAN
> #elif defined (__MIPSEL)
> # define __BYTE_ORDER __LITTLE_ENDIAN
> #elif
> # error "Neither __MIPSEB nor __MIPSEL, endianness configuration problem?"
> #endif
> 
> would make sense here too, to catch issues early on in case someone does 
> something silly with `-D' or `-U'.
> 
>   Maciej

I wonder if we should check here or if we should check in the shared
src/glibc/string/endian.h file.  We could verify that after including a
system specific bits/endian.h, __BYTE_ORDER is defined to either
__BIG_ENDIAN or __LITTLE_ENDIAN.

Maybe change this check in src/glibc/string/endian.h to have a '#else
#error' clause.  Is it ever legal to not define __BYTE_ORDER?

#if __BYTE_ORDER == __LITTLE_ENDIAN
# define __LONG_LONG_PAIR(HI, LO) LO, HI
#elif __BYTE_ORDER == __BIG_ENDIAN
# define __LONG_LONG_PAIR(HI, LO) HI, LO
#endif


Steve Ellcey


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]