From owner-freebsd-arch@FreeBSD.ORG Mon Nov 25 20:29:42 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 7D18C5B0 for ; Mon, 25 Nov 2013 20:29:42 +0000 (UTC) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52001272E for ; Mon, 25 Nov 2013 20:29:42 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id uo5so6515798pbc.15 for ; Mon, 25 Nov 2013 12:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5zoxdTmvcUvY5yfy6Aach/VTKs74WsceMXrnPO+IiuM=; b=TlxJML9sHilppMEaRDabG5+bFlSV1KcrVT6+FTPcrSDlzh7HkJ0Osj8ACiDnX4sO2u cLC5k4q/YHnBiDjOZoa0ZpRzz+/9XMqXWSq9hQJ9QWUmSlAQ9/gca3orzYFb1/nuEDfJ gW9yc4zm54uRYHblZL8bHC8zpy/PAWyqs9hMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5zoxdTmvcUvY5yfy6Aach/VTKs74WsceMXrnPO+IiuM=; b=VSChGZmJ6EBgWqs3vEEFa0b4zwj2h/TomhgZljwxQHjyKw0MyCTWiMrr2Y9gGKEC42 4R0qU+2BnegXECjY0egPUBvl2xgVxj/TQA6C3VAws7EjcYj3xPopajkoSZkmBQ0JLwHx wzP3OyT+q/XvH1b7FknoPvoLavvh7cPp27VzJkNxfUOzjjM4URfZDrnZm7Age4VWurTU jm9/UEwUExom6uUB9ATXRBmclRasvhEd0+lOsc314FGhWwxnO2ZnMokmghACiGRntgpD spwXTDKAepGqxSwslN/43qz044Kqgr/rwKliewu02JLBR5Z4hFKBZdoiZGPsiPh/Df8Y M8jA== X-Gm-Message-State: ALoCoQkWN80ZBXt/swmqn+y1RtO27un4cR3oLOPm/ekWNFES2BwAzor7oniYZ97gm4VoxYeNqe4f X-Received: by 10.66.13.70 with SMTP id f6mr3148796pac.180.1385411381800; Mon, 25 Nov 2013 12:29:41 -0800 (PST) Received: from hater-dm.corp.yahoo.com (nat-dip4.cfw-a-gci.corp.yahoo.com. [209.131.62.113]) by mx.google.com with ESMTPSA id xv2sm75293567pbb.39.2013.11.25.12.29.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 12:29:40 -0800 (PST) Message-ID: <5293B333.9070804@wemm.org> Date: Mon, 25 Nov 2013 12:29:39 -0800 From: Peter Wemm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: 1 << 31 and related issues References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 20:29:42 -0000 On 11/25/13, 11:48 AM, Eitan Adler wrote: > There are a few cases in FreeBSD where the expression (1 << 31) is used. > > However this produces undefined behavior as '1' is of type int. (see > 6.4.4p5: The type of an unmarked integer constant is the first of the > following list in which its value can be represented: int, long int, > long long int). The shift of 31 is illegal (see 6.5.7p4) if the size > of an int is 32. The same issue arises with 2 << 30 and 3 << 30. > > I have been working on fixing this issue in a few different projects. > The correct fix here is to use 1U as the literal instead. adrian@ has > advocated for the macros BIT32(bit) and BIT64(bit) which I would also > support. > > I have patches which fix the issue by using 1U in these cases. I did > not change non-broken cases. I also did not change contributed code. > > 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)) 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. FWIW2: we had an acpi bug with 1 << 31 way back in the early days. Back then, the compiler generated different code when compiled with -O2 vs not and 1<<31 had different values depending on compile time switches. -Peter