On Wed, 26 May 2010, Joakim Tjernlund wrote:
quoted text
> 
> 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.

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/