RE: [RFC] ordered comparison of pointer with integer zero warning in Wextra

["Dave Korn" <dave dot korn at artimi dot com>]

On 17 December 2006 12:56, Manuel LÃpez-IbÃÃez wrote:

> Currently Wextra warns about a pointer compared against integer zero
> with <, <=, >, or >=. This warning is not available in C++ (the
> documentation does not say this) and it is implemented in
> gcc/c-typeck.c (build_binary_op) in this manner:
> 
>       else if (code0 == POINTER_TYPE && null_pointer_constant_p (orig_op1))
> 	{
> 	  result_type = type0;
> 	  if (pedantic || extra_warnings)
> 	    pedwarn ("ordered comparison of pointer with integer zero");
> 	}
>       else if (code1 == POINTER_TYPE && null_pointer_constant_p (orig_op0))
> 	{
> 	  result_type = type1;
> 	  if (pedantic)
> 	    pedwarn ("ordered comparison of pointer with integer zero");
> 	}
> 
> That is, given int *p and -Wextra, the above code warns for p < 0 but
> not for 0 > p. Given -pedantic, we warn for both situations. This is
> also the only warning activated by both pedantic and -Wextra.
> 
> Taking into account the above, is there a reason for this?

  Looks like an oversight, the changelog doesn't suggest it would be intended to work that way:

http://gcc.gnu.org/viewcvs?view=rev&revision=9580

(build_binary_op): Also warn about ordered comparison of pointer with
zero if -Wall.

  Nothing to suggest the asymmetry was intentional, but of course it could have been.

> For me, the
> best would be to NOT enable the warning for Wextra, so I don't need to
> come up with a name for this warning flag. Otherwise, we would have to
> document that the warning is enabled by both pedantic and Wextra, so a
> user won't be surprised when the warning does not go away by using the
> Wno-* form just because pedantic is enabled.

  Well, the intent was clearly to enable the warning for Wall (later Wextra) in addition to pedantic, so I would suggest that in the absence of a positive reason to revert it, you should extend the second clause to cover Wextra as well.

  Heh.  Or you could always make it a divide-by-zero error instead :)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....