Messages in this thread | | | Date | Thu, 14 Oct 2010 17:36:33 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH] bitops.h: Widen BIT macro to support 64-bit types |
| |
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu, Oct 14, 2010 at 08:03:17AM -0700
> 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).
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
| |