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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
