On 05/23/2012 09:43 AM, Linus Torvalds wrote: > On Wed, May 23, 2012 at 9:31 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >>>> >>>> And it should return UL for shift values < 32 and ULL otherwise. >>> >> >> Why do you want that behavior? That seems bizarre... > > We *have* to have that behavior. > > A 64-bit value on a 32-bit architecture has fundamentally different > semantics than a 32-bit one. > > It expands arithmetic, but it has other semantic differences too. > Think "printf()" etc. We don't want to force people to do 64-bit > arithmetic on x86-32 when they are working with BIT(0), for chrissake! > > So if people make BIT(0) be a 64-bit value on a 32-bit architecture, > I'm going to run around naked with a chainsaw, and call people morons. > That's just not acceptable. > BIT(0), okay. I thought we were talking about BIT_64() here... Any reason we can't just tell people to use BIT() for a native "unsigned long" type (32/64 bits) and BIT_64() if they really want a 64-bit result? There are good reasons for the latter. Consider, for example: u64 msr; ... msr &= ~BIT_64(1); This *better* not be an unsigned 32 bit value, or we just chopped off the upper half. In this case and similar ones the 64-bitness of the result really matters. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|