Re: RFC: Warning fixes

[Daniel Jacobowitz <drow@false.org>]

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 <drow@false.org>
> > 
> > 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