lkml.org 
[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2010-05-26 18:51    [W:0.048 / U:0.864 seconds]
©2003-2014 Jasper Spaans. Advertise on this site