From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13056 invoked by alias); 31 Oct 2004 23:04:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13028 invoked from network); 31 Oct 2004 23:04:01 -0000 Received: from unknown (HELO tully.CS.Berkeley.EDU) (128.32.153.227) by sourceware.org with SMTP; 31 Oct 2004 23:04:01 -0000 Received: from tully.CS.Berkeley.EDU (localhost [127.0.0.1]) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/3.141592645) with ESMTP id i9VN40mL022060; Sun, 31 Oct 2004 15:04:00 -0800 (PST) Received: from tully.CS.Berkeley.EDU (hilfingr@localhost) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/Submit) with ESMTP id i9VN3xLF022057; Sun, 31 Oct 2004 15:04:00 -0800 (PST) Message-Id: <200410312304.i9VN3xLF022057@tully.CS.Berkeley.EDU> To: Andreas Schwab cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Setting long long bitfields Reply-To: Hilfinger@CS.Berkeley.EDU In-reply-to: Your message of Sun, 31 Oct 2004 19:40:28 +0100. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22053.1099263839.1@tully.CS.Berkeley.EDU> Date: Sun, 31 Oct 2004 23:04:00 -0000 From: Paul Hilfinger X-SW-Source: 2004-10/txt/msg00564.txt.bz2 > > One possible tweak, several of us have an aversion to "?:", it would be > > nice if it wasn't there :-) > > Like this perhaps: > > + ULONGEST mask = (ULONGEST) -1 >> (8 * sizeof (ULONGEST) - bitsize); Andreas, I had considered exactly that line, but unfortunately ran across the following really irritating provision in the C standard: "If the value of the right operand is negative or is *greater than or equal to* the width of the promoted left operand, the behavior is undefined." [I know why the provision is there, of course: many machines treat a shift of wordsize bits as 0, because they mask off bits to the left, but it's STILL irritating.] Now, I presume we will never encounter a bitfield size of 8 * sizeof (ULONGEST), but the original code apparently tried to bullet-proof against this possibility, so I just went along. Paul