On Mon, Nov 07, 2011 at 07:24:05PM +0100, Andreas Schwab wrote:
> Jeff King <peff@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html