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

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

> Clang's purpose is not to migrate code from C++98 to C++0x. That's a separate tool one could build with Clang.
> 
> Even once migrated, the user still has the ongoing risk of a 0 instead of nullptr & then clang's helpful diagnostics are silently suppressed. 

Hence the use of a style checker, which presumably will get run often.

> This is what one has to do to introduce a warning: implement it and see what the fallout is. With this warning, you're extremely likely to get an extremely low signal/noise ratio, especially because some coding standards actively encourage the use of 0 over NULL.
> 
> Indeed - and I assume the parentheses warning had a low signal to noise ratio when it was first introduced too (that was more my point of giving the example). People had to transform all their existing code to conform to the pattern first (easy with clang, harder doing it manually with GCC) and from then on the diagnostic would help them.

> Granted, parentheses probably had a higher s/n ratio than this warning would have. Assignments in conditionals are rare & the chance of misuse is higher, but still over a lot of code I'm sure there's a lot of legitimate usage that had to be fixed up when this warning was introduced, and all without the convenience of clang fixits. 

Yes, these are among the reasons why -Wparentheses makes sense for Clang but complaining about 0 in a pointer context does not. In any case, my decision stands: we will not accept a warning about '0' being used in a pointer context at this time.

> Hmm: should the parentheses warning offer a fixit to add parens? It's already suggesting as much in text.

IIRC, it does have Fix-Its on the notes.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110826/bb63745f/attachment.html>