Date: Tue, 26 Nov 2013 01:27:46 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-arch@freebsd.org Subject: Re: 1 << 31 and related issues Message-ID: <5293EB02.8060509@rlwinm.de> In-Reply-To: <20131126075626.A4024@besplex.bde.org> References: <CAF6rxgm9Q9ckhKR75sKRjAmebGGNM_jpDjiUqeUd%2B=WbCf6TRw@mail.gmail.com> <5293B333.9070804@wemm.org> <20131126075626.A4024@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5293EB02.8060509>