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

Hmm - I can see the concept, but it doesn't see to match up with my
experience/understanding. I tend to compile with everything on (the old
incantation with G++ was "-Wall -Wextra -pedantic -ansi") which provides a
whole bunch of things over the baseline. It's just the case that this usage
is really that rare? That most people compile without any warning flags at
all?

I suppose I could believe that & most users aren't nearly so interested in
correctness/portability as the language lawyers/academic purists/etc. Though
if it's just a matter of adding a feature that'd be useful for some people &
unseen by the man-on-the-street, that doesn't seem to dismiss the idea
entirely. Then the only reason not to do it is cost (which I'm offering) &
ongoing cost of having that added complexity in the compiler (which I agree,
is something to be cautious about at every turn - I don't like adding
unnecessary surface area if I can help it).


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

Sorry, I'm not quite following you here. Which cases of NULL vs 0 confusion
do you think should be caught & which ones should be allowed?

I take it you mean that integer 0 literals should be acceptable as pointer
literals (agreed, at least in C++98 - Stroustrup's argument that it helps
show you the reality/ambiguity in your code is sufficient for me to
believe/understand that some people do this intentionally. But in C++11 I
think it can do better & can help eliminate a source of bugs that use of the
literal 0 or NULL can produce that cannot be caught in C++03 code because
there is no better feature to describe the author's intent) but uses of NULL
in non-pointer contexts should be caught.

I'd say all uses of NULL in non-pointer contexts should be caught.
Technically a C++ implementation is actually free to define NULL as nullptr,
so at the very least you have a (theoretical, of course, no current
implementation could practically make NULL nullptr today) a portability
concern if you use NULL in non-pointer contexts.

[I have to say, I'm kind of surprised no one else on the list has any
opinion on this at all - which perhaps indicates that I'm barking up the
wrong tree]


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

Fair enough. Is there an appropriate reference set/process that should be
used - is this the sort of thing where we would add the warning, on by
default, see what the buildbots/etc cough up, or is there some way to
replicate all that test coverage locally to avoid randomizing the
bots/developers?


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

Fair enough - I was just wondering whether that was the case here so I could
understand which warnings were consistent with your philosophy & which ones
were concessions to GCC compatibility which aren't valid precedent for
making similar features/changes that don't increase GCC compatibility.


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

OK.


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

Right - this comes back to the point about GCC above. I'm trying to
understand the philosophy you're going for so I can make a sound argument in
terms of that philosophy. If the existing warnings aren't consistent with
that philosophy then I can't really draw conclusions about what other
features clang should have by looking at them. So if the bool conversion and
NULL in arithmetic warnings are ones you think are appropriate, then from
that I can try to explain why these other warnings would have similar
value/purpose.

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