From owner-cvs-all Sun Oct 20 18:13:42 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CBAB37B401; Sun, 20 Oct 2002 18:13:41 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 280F043E75; Sun, 20 Oct 2002 18:13:40 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA08205; Mon, 21 Oct 2002 11:13:29 +1000 Date: Mon, 21 Oct 2002 11:24:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Garrett Wollman Cc: "M. Warner Losh" , , Subject: Re: [src] cvs commit: src/sys/i386/pci pci_bus.c In-Reply-To: <200210202019.g9KKJ2xU054169@khavrinen.lcs.mit.edu> Message-ID: <20021021110621.J8959-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 20 Oct 2002, Garrett Wollman wrote: > < said: > > > We'd need it for each width. The PCI standard defines that no > > hardware decoding the address is to return 0xff for each of the bytes > > read. > > The correct way to write that would be ~(appropriate_width_unsigned_type)0. Er, no. E.g., ~(uint8_t)0 is no different from ~0, since the operand of `~' suffers (sic) the default promotions before the operand is applied, and Standard C's "value-preserving" promotions are especially broken for (uint8_t)0. A less incorrect way to write this is (appropriate_width_unsigned_type)~(appropriate_width_unsigned_type)0. This works on normal 2's complement machines but fails on normal 1's complement machines. E.g., when the unsigned type is uint8_t, the intermediate result is ~0 again. ~0 is -1 on normal 2's complement machines and -0 on normal 1's complement machines. Casting this to uint8_t gives 0xff on normal 2's complement machines and (I think) 0 on normal 1's complement machines. On abnormal machines (even 2's complement ones), you also have to worry about trap representations. ~0 probably sets trap bits if there are any, so it can probably cause a trap either when it set or when it is used. A correct way to write this is closer to the original code: (appropriate_width_unsigned_type)-1 The result of this is clearly specified in Standard C (C90 6.2.1.2) and is independent of the type of arithmetic (1's complement, etc.). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message