[cfe-dev] Possibly invalid enum tautology warning

[Peter Geoghegan]

On 8 August 2011 18:32, John McCall <rjmccall at apple.com> wrote:
> 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?

It wasn't unidiomatic. I'd say that it was the most natural way of
expressing the problem; the value of the enum had to be used as an
array subscript, and the enum might well have been unsigned for all we
knew - arbitrary third party code is not to be trusted. Since I've
already fixed all warnings when building with Clang that are unique to
Clang, I don't really represent the Postgres community here any more.

I can't see the suppression of this warning as described diminishing
the value of the compiler for everyone; I can see it increasing
Clang's value. That's what I want - otherwise, I wouldn't be spending
my time debating it with you. While this issue may not be of any great
consequence, it is definitely of much greater consequence to Clang
than to Postgres. This warning is absolutely inconsequential to
Postgres. I like Clang too though.

> 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?

Perhaps you don't. Is that intended to be a reductio ad absurdum
argument? If so, I don't find the reduction to be absurd, because GCC
doesn't show any tautology warnings there. Have I missed something?

> 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.

That's true. The idiosyncratic Clang thing is that Clang complains
about it. I'd be all in favour of that complaining if it was
inherently valid across compiler platforms; at the moment, I am not
convinced of that.

Of course, unlike the last thread I started on Clang's warnings, it's
not as if I feel that strongly about this. Apparently you don't see it
quite as I do; you want the compiler to correct the code while making
assumptions about the platform or compiler in use (assuming that it
will only be the current platform or one like it). I want the compiler
to provide objective diagnostics in a vacuum. I respect these
differences. I just disagree.

Clang is currently being used as a sort of lint tool by many, because
its diagnostics are much better than GCC's. People who use it in this
way are perhaps more likely to be sympathetic to my view - it should
be possible to use a compiler as a lint tool without caring about the
binaries it produces, provided the logical input to the compiler is
the same (which is not to say I consider Clang to be a mere lint
tool). I'm sure you could list corner cases or grey areas here, but
this is just an ideal, and like most ideals it's never going to be
completely realised. The behaviour that I'm suggesting we might want
to consider here though, removing the warning under these
circumstances, could easily be realised.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services