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). So no. I do not think BIT() should be 64-bit. It's "unsigned long". Look at all the other things around it, and look at all the historical uses. Linus -- 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