linux-next: build warning in Linus'tree
in [Kernel]
|
From: Linus Torvalds on 26 May 2010 12:50 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joakim Tjernlund on 26 May 2010 13:40 Linus Torvalds <torvalds(a)linux-foundation.org> wrote on 2010/05/26 18:46:11: > > 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. Ouch! But here -Wundef really helps. > > So no. The glibc model is _not_ any better in practice. In the kernel it is since it breaks the compile. The breakage my patch introduced is a sign of that, right? > > > 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- Not in general, but my case could have been avoided, I sure there are others too. Why else does some header files bother with __BYTE_ORDER? > specific. So anybody who has this problem is likely doing something iffy > to begin with. hmm, so then I guess the existing use of __BYTE_ORDER in the kernel should be removed? > > Besides, you can solve it cleanly by simply avoiding the crazy glibc > semantics entirely. IOW, the CONFIG_BIG_ENDIAN option I suggested (and CONFIG_BIG_ENDIAN would have helped me with my lib/crc32.c problem but it does not prevent silent breakage so I figured the glibc model would be better. Is it such a big difference, readability wise, between #ifdef CONFIG_BIG_ENDIAN and #if __BYTE_ORDER == __BIG_ENDIAN that you rather risk silent breakage? > again, you should damn well not export things that depend on it to user > space - there are architectures where user-space might be switchable) Such arch exists but does any of them run linux in both modes? Jocke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 26 May 2010 13:50
On Wed, 26 May 2010, Joakim Tjernlund wrote: > > > > So no. The glibc model is _not_ any better in practice. > > In the kernel it is since it breaks the compile. The breakage > my patch introduced is a sign of that, right? In the kernel it is _worse_, because it breaks all the years and years of code we have. The thing is, "reality" > "theory". Besides, the kernel model is a lot denser, more straightforward, and in my opinion much less likely to cause problems due to having just two clear identifiers rather than that extraneous and useless __BYTE_ORDER one. So even in theory, I don't agree. It's not like we've really had problems with our model. > hmm, so then I guess the existing use of __BYTE_ORDER in the > kernel should be removed? Yes. Except in the places where it exists solely due to user-space header exporting (and there it generally is a big hint that something is wrong anyway, as mentioned). From my quick grep (read: "not verified") there's a couple of files like that. It's probably not worth trying to change (one of them is about __BIG_ENDIAN_BITFIELD, which is due to people using bitfields for transferring data. That _is_ misdesigned. Bitfield ordering is even less well defined than byte order, and if you have to use those bitfield ordering things, it's almost always a sign that you shouldn't have used bitfields, and used explicit shifts-and-masks instead) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |