From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Thu, Oct 14, 2010 at 08:03:17AM -0700 > On Thu, Oct 14, 2010 at 3:58 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > >> > >> Ok, so BIT() should be fixed to work with the largest type available, > >> IMHO. Let me cook up something. > > > > Maybe something like the following. Build-tested with the crosstool > > (http://www.kernel.org/pub/tools/crosstool) on the following arches: > > alpha blackfin cris hppa64 ia64 mips64 sparc. > > > > Any objections? > > Yeah. I object. I have no idea what this will change for everything > else that expects bitops to work on unsigned long values. > > I really think that the bug is not in the BIT() definition, but in the > use. If somebody wants a non-unsigned-long bit field, they had better > not use bitops.h. > > And no, just changing the BIT() macro to return a 64-bit value is > _not_ trivially safe. Due to C type rules, now all arithmetic using > BIT() will suddenly be 64-bit, which is often *much* slower, and can > introduce real bugs. > > On many architectures, a 64-bit non-constant shift will even end up > being a function call. And if the thing is used in a varargs function, > the argument layout will be totally different. We've also had several > issues with 64-bit types and switch() statements, for example. And a > quick grep for '\<BIT(' shows that non-constant cases are not unheard > of, and there's a lot of random use where it is not at all obvious > that it's safe (because it's used for defining other defines). Concerning safety, I actually had a version which did check the bit number supplied as an arg for overflowing but this failed when using BIT() in struct initializers: .struct_member = { BIT(bla) } But thanks for the detailed explanation! This makes perfect sense; it was too much wishful thinking on my part to assume that a ULL BIT() would be fine after checking that all arches support the unsigned 64-bit type. I'm much better off with a local BIT_64() or similar, definition. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html