Messages in this thread | | | Date | Wed, 26 May 2010 09:46:11 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: linux-next: build warning in Linus'tree |
| |
On Wed, 26 May 2010, Joakim Tjernlund wrote: > > 1) It silently breaks when neither of {__LITTLE_,__BIG}_ENDIAN (or both)are > defined depending on the endianess of the target CPU. > The glibc model generates a compile error if you forget to include __BYTE_ORDER.
Umm. Except when it doesn't (yes, Linux has the "Wundefined" thing, and has had for a long time). I've seen the glibc model do the wrong thing exactly because traditional C semantics is "undefined symbol is 0 in evaluations"
Try compiling this
#include <stdio.h>
#if NOT_HERE == NOT_THERE int main() { printf("Hello world!\n"); } #endif
and even with -Wall it compiles perfectly happily.
So no. The glibc model is _not_ any better in practice.
> 2) It clashes with user space so one cannot use it in exported header files.
Which is annoying, I agree. But you shouldn't generally use kernel headers for user space anyway, much less export anything that is byteorder- specific. So anybody who has this problem is likely doing something iffy to begin with.
Besides, you can solve it cleanly by simply avoiding the crazy glibc semantics entirely. IOW, the CONFIG_BIG_ENDIAN option I suggested (and again, you should damn well not export things that depend on it to user space - there are architectures where user-space might be switchable)
Linus
| |