From owner-freebsd-arch@FreeBSD.ORG Mon Nov 25 21:41:09 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9460F73 for ; Mon, 25 Nov 2013 21:41:09 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 8AFDB2BC3 for ; Mon, 25 Nov 2013 21:41:09 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 2DF69104AD86; Tue, 26 Nov 2013 08:17:23 +1100 (EST) Date: Tue, 26 Nov 2013 08:17:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Wemm Subject: Re: 1 << 31 and related issues In-Reply-To: <5293B333.9070804@wemm.org> Message-ID: <20131126075626.A4024@besplex.bde.org> References: <5293B333.9070804@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=l52YrXMppdkA:10 a=6I5d2MoRAAAA:8 a=xOKQsN7nvL1WrRQpgtsA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 21:41:09 -0000 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