<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>Just because someone is compiling with C++0x doesn't mean they want to automatically upgrade their code to C++0x.</div>


</div></div></div></blockquote><div><br></div><div>Sure - though warnings can be disabled by default and/or by users.</div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></blockquote><div><br></div><div>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?<br>
<br>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>
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. </div></div></blockquote><div><br></div></div><div>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.</div>
<div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>Is it reasonable to generalize the existing checks into:<br><br>* 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"?</div>
</div></blockquote></div></div><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>
* 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)?<br>
</div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></blockquote><div><br></div><div>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? <br><br>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.<br>
<br>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. </div>
<div><br></div><div>[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]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div> 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.</div></div></div></blockquote>
<div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>
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).</div>
</div></blockquote><div><br></div></div><div>GCC compatibility sometimes trumps our rational approach to warnings (and compiler design <g>). </div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div>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.</div>
</div></div></blockquote><div><br></div><div>OK.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im">
<br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.</div>

</div></div></blockquote><div><br></div><div>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)</div>

</div></blockquote><br></div></div><div>Warnings are intended to find potential problems in the source code. Style migration is the domain of separate tools.</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>- David</div></div><br>