This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bizarre warnings


On Sat, 12 Sep 1998 17:31:06 -0400 (EDT), Todd Vierling wrote:
>On Sun, 6 Sep 1998, Zachary Alexander Weinberg wrote:
>
>: t-coverage/string-test.inc:314: warning: unsigned value < 0 is always 0
>: t-coverage/string-test.inc:346: warning: unsigned value >= 0 is always 1

I did some more investigation.  Code of the form

#define get_number(from, to)				   \
  do {							   \
    val = 0;						   \
    if (*rp < '0' || *rp > '9')				   \
      return 0;						   \
    do {						   \
      val *= 10;					   \
      val += *rp++ - '0';				   \
    } while (val * 10 <= to && *rp >= '0' && *rp <= '9');  \
    if (val < from || val > to)				   \
      return 0;						   \
  } while (0)

int
main(void)
{
  char *rp = "0123456789";
  unsigned int val;

  get_number(0, 10);
  return val;
}

will trigger the warning on the line of the macro invocation.  The
problem expression is

if (val < from || val > to)

Since the macro is general - this is pared down from a large piece of
code that calls the macro several times with different arguments - the
comparison with from is necessary and correct.

Normally I would write this off as "don't use -W with that file" but
one of the macros I'm having problems with is defined in glibc2.1's
string.h.  I think it's reasonable to expect that system headers don't
generate warnings.

What I'd like is a way to shut off this warning on a per-expression
basis.  The notation

if ((from && val < from) || val > to)

seems natural enough as a way of assuring the compiler that I know
what I'm doing.  However, the current compiler still generates the
warning in this case.  This is because the warning comes from
c-common.c:shorten_compare() which doesn't know anything about the
context of the comparison it's optimizing.

A fix might be to change the caller of shorten_compare() so it doesn't
bother examining the right side of a TRUTH_AND_EXPR at all when the
left side is constant zero.  && short-circuits so you don't even need
to look for side effects.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]