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

    Try compiling this

    #include <stdio.h>

    int main()
    printf("Hello world!\n");

    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)


     \ /
      Last update: 2010-05-26 18:51    [W:0.020 / U:14.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site