| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 27 Aug 2008 14:26:35 -0700 (PDT) From: Linus Torvalds <torvalds@...ux-foundation.org> To: David Vrabel <david.vrabel@....com> cc: Al Viro <viro@...IV.linux.org.uk>, Roland Dreier <rdreier@...co.com>, Kernel development list <linux-kernel@...r.kernel.org>, linux-usb <linux-usb@...r.kernel.org> Subject: Re: [patch] Add helper macros for little-endian bitfields On Wed, 27 Aug 2008, David Vrabel wrote: > > But why is this worthy of a crispy flaming? I've not seen anything > definite beyond a somewhat vague 'some compilers don't optimize > bitfields very well'. Actually, it's not that compilers often optimize bitfields really badly. It's also that bitfields are a total f*cking disaster when it comes to endianness. As you found out. Bitfields are fine if you don't actually care about the underlying format, and want gcc to just randomly assign bits, and want things to be convenient in that situation. But _if_ you care about the underlying format, then inevitably the bitfield costs will be much higher than just using bit operations on a "u32" or similar. Your helper macros are horrible compared to just making the bits work out right to begin with, and using the standard byte order things. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists