[cfe-dev] Possibly invalid enum tautology warning

[John McCall]

On Aug 8, 2011, at 1:42 AM, Peter Geoghegan wrote:

> On 8 August 2011 01:50, John McCall <rjmccall at apple.com> wrote:
>> I still consider this a useful warning, even on enum types.  When I
>> was implementing it, I was persuaded that we ought to have a
>> special case for comparing against an enumerator which happens
>> to be zero, because that was indicative of a particular common
>> and harmless idiom (specifically, things like if (v < v_first || v > v_last)).
>> I'm loathe to extend that to a direct comparison against zero, where
>> it really does seem like the programmer is specifically testing for
>> an error case and might be surprised to realize that their test never
>> triggers.  People who really do want to litter their code with defensive
>> checks like this should just disable the tautological comparison
>> check — it's not likely that it would only ever come up with enums.
> 
> Respectfully, I have to wonder if that's a practical attitude. They
> may not want to "litter" their code. They may just want to do this
> exactly once, as for example Postgres was before a patch was committed
> that sidestepped the issue. Should they still have to disable the
> tautological comparison check?

There are simple, idiomatic ways to suppress this warning
on a site-by-site basis.  You found one yourself.  Why is the answer
to diminish the utility of the compiler to other users because Postgres
was doing something unidiomatically?

>> Well, you're assuming that comparisons like this are always in overly-
>> defensive code where the tautology is harmless.
> 
> No, I'm not. I'm quite simply taking issue with the fact that the
> tautology exists only because of a factor that is implementation
> defined.  /The tautology is not essential to the code/.

We've gone over this before.  How do you differentiate this from
anything else arising from something implementation-defined,
like the signedness of wchar_t?  

I must also note that we are completely in accord with GCC on the
choice of signedness for this enum;  this is not some idiosyncratic
clang thing.  This is how it works for probably the majority of your
users.

John.