From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26043 invoked by alias); 28 Dec 2006 23:09:35 -0000 Received: (qmail 26028 invoked by uid 22791); 28 Dec 2006 23:09:34 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 28 Dec 2006 23:09:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H04NK-0006HT-1g; Thu, 28 Dec 2006 18:09:26 -0500 Date: Thu, 28 Dec 2006 23:09:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: RFC: Warning fixes Message-ID: <20061228230925.GA23775@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20061228195828.GA18628@nevyn.them.org> <200612282256.kBSMu65R022410@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612282256.kBSMu65R022410@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00337.txt.bz2 On Thu, Dec 28, 2006 at 11:56:06PM +0100, Mark Kettenis wrote: > > Date: Thu, 28 Dec 2006 14:58:28 -0500 > > From: Daniel Jacobowitz > > > > Any comments on these, or shall I commit them? Regardless of the configure > > patch, we might as well fix the bugs. > > Some of these are really scary. Can you check for regressions on i386 Linux? I haven't yet, but definitely will before checking them in. > > - if ((sig >= TARGET_SIGNAL_FIRST) && (sig <= TARGET_SIGNAL_LAST)) > > + if (sig <= TARGET_SIGNAL_LAST) > ISO C clearly states that enumeration constants have type 'int', so > sig could be negative, and we defenitely want to catch that case. If > GCC thinks it knows that (sig >= TARGET_SIGNAL_FIRST), I think it is > being too smart for its own good. If you want to catch that case, then it's a good thing you had this warning here to look after you, because the old code might not do it either :-) Though it always works out, after promotion, because of the second test. This happens because TARGET_SIGNAL_FIRST is an "int", but "sig" is an enum. The choice of compatible integer type for an enum is implementation defined, and GCC documents: * `The integer type compatible with each enumerated type (C90 6.5.2.2, C99 6.7.2.2).' Normally, the type is `unsigned int' if there are no negative values in the enumeration, otherwise `int'. If `-fshort-enums' is specified, then if there are negative values it is the first of `signed char', `short' and `int' that can represent all the values, otherwise it is the first of `unsigned char', `unsigned short' and `unsigned int' that can represent all the values. There's nothing negative in the enum, ergo GCC chooses unsigned int. And therefore TARGET_SIGNAL_FIRST is promoted to unsigned int. The warning is a bit annoying, though. We can't portably tell whether the type of sig will be signed or unsigned. Perhaps we should force sig to be an int before bounds checking, instead, and I should file a GCC bug report. How's that sound to you? -- Daniel Jacobowitz CodeSourcery