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

[Douglas Gregor]

On Aug 25, 2011, at 11:32 AM, David Blaikie wrote:

> Just because someone is compiling with C++0x doesn't mean they want to automatically upgrade their code to C++0x.
> 
> Sure - though warnings can be disabled by default and/or by users.

Off-by-default warnings are not a mechanism to subvert our normal processes for vetting a warning. In general, we should avoid off-by-default warnings: if it's not good enough to turn on by default, why do we have it at all? The vast majority of users will never see an off-by-default warning.

> It seems like it would be pretty limiting to be entirely agnostic to 'better' ways of doing things until the old way is explicitly deprecated by the standard. 

This is an intentional and desirable limitation. A compiler is not a style checker, nor should it ever be. Now, if the warning is pointing out an actual problem that couldn't be caught before… that's something entirely different.

> Is it reasonable to generalize the existing checks into:
> 
> * using NULL in a non-pointer context (potentially still just leveraging GCC's __null). Special casing for arithmetic doesn't catch lots of other places. Is "int i = NULL;" (the more common "char c = NULL;" I suppose - which is arguable, perhaps? but seems to me as wrong as the other cases that already have NULL warnings) any more reasonable than "NULL < 3"?

> * using anything other than 0/NULL/nullptr in a pointer context? Special casing for boolean seems to be a bit overly narrow. What about char zero, for example? Though I suppose 0L might still be in the realm of "things people do intentionally", so perhaps a blacklist (boolean & char) is still preferred over a whitelist (0, NULL, nullptr)?

Any integral literal 0 seems like it should be allowed here. Otherwise, it seems entirely reasonable to warn about NULL vs 0 confusion, since this is a source of bugs in practice. The question is whether such a warning will produce too much noise; the only way to figure that out is to implement it and run it across a pile of code.

> I guess the existing warnings came out of GCC compatability so perhaps they need to be preserved as much as possible by name/semantics, which still leaves the "what to do when warnings overlap" question (only relevant if the above is reasonable).

GCC compatibility sometimes trumps our rational approach to warnings (and compiler design <g>). We're fine with extending the behavior of warnings that GCC also has (GCC changes them from one version to another, too), so long as the extension is good.

> I understand what you're getting at, but I consider it the domain of a separate style checker rather than something that should be implemented as a warning.
> 
> Is this true of the existing NULL/null pointer/false warnings, or is there some distinction between those & any new/modified warnings? (including the limited, but more general ones I've mentioned above, leaving aside the issue of wholesale migration to nullptr, NULL, or 0)

Warnings are intended to find potential problems in the source code. Style migration is the domain of separate tools.

	- Doug

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