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

[David Blaikie]

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

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.


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


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

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

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