Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member

From: Jeff King <peff@peff.net>
Date: Nov 7, 2011, 18:34 UTC
Message-ID: <20111107183402.GA5118@sigill.intra.peff.net>
In-Reply-To: <m2k47b4wqi.fsf@igel.home>

On Mon, Nov 07, 2011 at 07:24:05PM +0100, Andreas Schwab wrote:

Show 7 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Yes, but now you are getting into implementation-defined behavior, which
> > is also something to avoid.
> 
> The whole point of the statement is a sanity check to uncover bugs.  If
> you remove the first condition you completely ruin its point.

I'm somewhat dubious of the value of a bug-check that may or may not actually kick in depending on your compiler's choice of enum representation, and whose bugs are generally easier to check via static analysis (i.e., making sure the enum value is one of the enumerated values when it is initialized or assigned).

Yes, static analysis can miss some bugs (like passing the address of the enum through a void pointer (e.g., when memset'ing a struct)). But couldn't it just as easily be out of range in the other direction?

It seems like the bug trying to be caught is probably something like:

  enum foo v = function_which_returns_value_or_negative_error();
  if (v < 0)
     die("BUG");

But in that case the bug is on the first line, and it is easily caught by static analysis, no?

-Peff