1 << 31 and related issues

[Bruce Evans]

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.

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