1 << 31 and related issues

[Peter Wemm]

On Mon, Nov 25, 2013 at 1:17 PM, Bruce Evans <brde at optusnet.com.au> 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.

Yep.  Invalid or undefined behavior in crypto or security critical
code is hardly a good thing, even if it usually works out ok.

>> 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.

Well, when we had a cpumask_t as a 64 bit integer type and did (1 <<
cpu) in both MI and MD code, it was a pretty big deal before cpuset_t
came along.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.