Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 14 Oct 2010 08:03:17 -0700 | Subject | Re: [PATCH] bitops.h: Widen BIT macro to support 64-bit types |
| |
On Thu, Oct 14, 2010 at 3:58 AM, Borislav Petkov <bp@amd64.org> 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
| |