1 << 31 and related issues

[Jan Bramkamp]

On 25.11.2013 22:17, Bruce Evans wrote:
> On Mon, 25 Nov 2013, Peter Wemm wrote:
> 
>> On 11/25/13, 11:48 AM, Eitan Adler wrote:
>>> There are a few cases in FreeBSD where the expression (1 << 31) is used.
>>> ...
>>> An incomplete listing of the issues available here:
>>> http://people.freebsd.org/~eadler/files/1..31.txt
>>
>> I find it particularly enjoyable to see things like this in crypto code:
>>
>> crypto/heimdal/lib/hx509/ref/pkcs11.h:#define CKF_EXTENSION       
>> ((unsigned
>> long) (1 << 31))
>> crypto/openssh/pkcs11.h:#define CKO_VENDOR_DEFINED    ((unsigned long) (1
>> << 31))
> 
> I almost said that in my earlier reply too.
> 
>> FWIW,  This came up in both ia64 and amd64 early days.  Most of this was
>> hunted down in the kernel back then.  Obviously some has crept back in,
>> or is in contrib or driver code.
>>
>> The problem there is bigger though.  On 64 bit machines, 1u << N tends
>> to get used where N > 32 as well.  1u << 33 is an overflow and doesn't
>> extend up into the 33rd bit.  We changed most uses to 1ul << N where
>> this was likely.  This did predate the BIT* macros you referenced.
> 
> I don't think anyone expected 1u << 33 to work.

It would work on an ILP64 platform like Cray Unicos or HP Tru64 but most
codebases will explode in flames on those platforms among other reasons
because they are ILP64.

> This reminds me to complain about use of the unsigned type again :-).
> Compilers should warn for 1 << 31, and do warn for (1 << 30) + (1 << 30),
> but an unsigned type almost anywhere in the expression must prevent
> the warning.  Compilers do warn for (1u << 32), however -- cases where
> the shift count is too large or negative are udnefined even for unsigned
> types.  Cases like (1u << 31) + (1 << 30) + (1 << 30) are defined (this
> one has value 0 with 32-bit unsigned's).
> 
> Bruce
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"