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

[David Blaikie]

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

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

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


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

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