[cfe-dev] null pointer literals, warnings, and fixups

[Titus von Boxberg]

Am 27.08.2011 um 01:34 schrieb Douglas Gregor:

> 
> On Aug 26, 2011, at 4:18 PM, David Blaikie wrote:
> 
>> We're going in circles. I think we agree that preferring nullptr to 0:
>> 
>>   (1) May prevent some mistakes arising from confusion between 0 being both an integer value and a null pointer , and
>>   (2) Is not in widespread use in C++ code today.
>> 
>> Your suggested warning about the use of 0 in a pointer context only makes sense if a particular code base follows this convention to start with, or the user wants to establish this convention. The former case is too rare now to consider (per (2)),
>> 
>> Doesn't that make a perfect case for an off-by-default warning, then? Rather than users having to employ a separate tool (though, I admit, if a clang plugin is easy/lightweight enough I'm not at all averse to doing this sort of thing as a plugin. I'll certainly follow up on that) to ensure they don't make such mistakes.
> 
> I have already expressed my reasons for not wanting to introduce yet more off-by-default warnings.
> 
>> It does seem a pity that even new C++ code would suffer the ills of old C++ code because the compiler is being overly cautious about existing code (that would be fairly easy to fix up in the case where someone is actually using C++0x features in their code already, and suppressed if they're just looking to ensure their code compiles as both C++98 and C++0x). Perpetrating more pointer mistakes even after features designed to help developers here have been standardized.
> 
>> and the latter case is a style-checking issue that should not be a compiler warning.
>> 
>> The point I'm making is that it's more than style - it has practical benefits that the compiler can understand the developers intent & provide diagnostics. How does the user know they're missing out on those useful diagnostics? Even if they know the diagnostics exist, it'll catch all their spurious NULL usage, but not the other way around (0 as null pointer) - that will be silently accepted without the use of an external tool.
> 
> Every purveyor of a convention claims that it's more than style, and it has practical benefits if only developers would follow that convention. That's not relevant here: the convention is not widespread enough to codify it in a compiler.
> 
> If you consider this convention to be important, by all means write a style checker and evangelize the convention. Convert the masses, and they'll come banging on our door for compiler support.

I'd say that the argument of "that's only style" vs. "that's real (?)" is leading nowhere because what's defined as being not only style comes from a tradition that was not to the least established by compiler warnings.
I have the impression that you are dismissing the idea of new warnings out of an (understandable but not very good) argument "enough is enough".

We're maintaining and extending a c++ code base with code that's in part way over 10 years old. I feel it's perfectly normal and reasonable to introduce quite a few corrections because of warnings that eventually got introduced. I'm not fond of all warnings (like  the parentheses stuff) but grateful for most of them.

Another example, only a slight deviation: I have forbidden the use of C-style casts in our codebase, being very thankful for gcc implementing -Wold-style-casts. Following your opinion one could reasonably argue that old-style casts are so ubiquitous that this warning is no good for (and clang still ? seems to ignore this command line flag).
Just 2 days ago we found that our software accidentally made use of a bug (or at least a quirk) even in such an old and mundane thing as libstdc++'s bind1st/bind2nd, there caused by the use of a function style cast (which was, presumably, not even meant to be such a cast).
Ok, the example is not perfect because we could find the bug not by compiler warnings but only because we analyzed compilation errors of our code when using the new libc++. Nonetheless I guess that also other software does benefit from this warning.

To the "migration to C++0x":
I understand your mails that it is some distant misty future that will bring "C++0x".
As far as I know the standard has been accepted, and it will be published in this year. At least compilers based on EDG seem to implement quite a lot of the new stuff already.
Maybe it's time for you to replace that "0x" with "11", or maybe "12", to get the impression that the time has come now and not at some always equally distant hexadecimal digit yet to be enumerated. (That's also a suggestion for the compiler driver's command line flag ;-).
That implies that your argument about the parentheses warning being "preestablished" since gcc 4.3, as well as the headers that might be shared with older code bases is not fruitful *if* you accept C++11 as as current and reasonable goal for clang. There are no "preestablished" conventions with C++11 around yet, but that does not imply that they couldn't be developed, or that clang couldn't take part of that development on the leading edge. If that was the case, then why start with then C++0x before having "preestablished" conventions to rely upon?

Currently, we are "migrating" (what do you mean with that, anyway?) our software to C++11 which started with not much more than to pass the flag to the compiler, and grew into our own table of features still forbidden or already endorsed.
I guess that we will not be the only tough/stupid guys who do that. Maybe most just don't show up on this ML. At least you should take not only open source projects into account: One could always point e.g. to wxWidgets, being quite a large and renonwned project but known to be very reluctant introducing newer language features. For wxWidgets you might wait for C++24 or whatever to start implementing C++11 stuff ;-)
I would be very thankful if clang would bring warnings and hints about how to improve quality by use of features of the new standard.

To style checker vs. compiler:
I assume that style checker tend to be run way less often. And I assume that style checkers are usually of lower quality than compilers for obvious reasons. I do not trust style checkers (as I only very reluctantly trust a single compiler+library, a habit that has payed off during the years, ref the above bind2nd example).
Also for this reason I find it very helpful if the compiler as the "messenger of final truth"  can detect more and more quirks in our code upfront.
Warnings may not only be good for your code but also for the trust in the compiler that issues them.

I'd try to draw the line between style checker and compiler given the complexity of the idioms and constructs in question.
Whenever it's a more or less "simple" or "local" expression the compiler should warn about that.
Though I cannot define "simple" well I think that all would agree that a usage of a single literal in a local expression is "simple", at least from the user's perspective.
On the other hand I would agree that at least parts of g++'s -Weffc++ belong to a style checker, not a compiler.
Warnings that suggest nullptr instead of literals or maybe even NULL, however, I'd like to see in clang, so that was a quite lengthy bang on your door ;-)

Hope that helps.

Regards
Titus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110827/7961bd21/attachment.html>