[cfe-dev] Possibly invalid enum tautology warning
John McCall
rjmccall at apple.com
Mon Aug 8 10:32:13 PDT 2011
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.
More information about the cfe-dev
mailing list