<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 26, 2011, at 11:37 AM, David Blaikie wrote:</div><br class="Apple-interchange-newline"><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 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></div></div></blockquote><div><br></div><div>Yes. The vast majority of projects I see compile without changing a single warning flag. And, as Ted's recent experiments with -Weverything have shown us, warnings that aren't turned on by default get very little testing coverage and tend to be broken (or break over time).</div><br><blockquote type="cite"><div class="gmail_quote"><div>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></blockquote><div><br></div><div>I am very concerned with the ongoing cost, and the accumulated drag on code side and compilation performance from having so many (typically unused) knobs.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><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.</div></div></blockquote><div><br></div><div>Yes, 0 should be acceptable as a pointer literal, as should 0L. This is convention for a large number of projects and programmers.</div><br><blockquote type="cite"><div class="gmail_quote"><div> 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></div></div></blockquote><div><br></div><div>You're assuming that programmers want to migrate all of their code to C++0x and its idioms. Perhaps when C++0x is ubiquitous and the majority of code we see if compiled as C++0x, this will make sense, but that's certainly not the case now. Perhaps in the future, (long?) after Clang has switched its default dialect to C++0x, we can make this assumption. </div><div><br></div><div>For the other side of the equation, check out the warning + Fix-It for this code:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> struct Point { int x, y; } p = { x: 10 };</span></div><div><br></div><div>Here, we do have a Fix-It that migrates from (old, non-standard) GNU designated initializer syntax to the C99 syntax. There are two major differences between this warning and a warning that would replace "0" with "nullptr":</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1) The old syntax is not supported by any standard</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2) Clang defaults to the standard providing the new syntax (C99)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>3) The standard providing the new syntax has been available for a very long time and is widely implemented</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>I'd say all uses of NULL in non-pointer contexts should be caught. </div></div></blockquote><div><br></div><div>I'm fine with this.</div><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> 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></blockquote><div><br></div>There's no reference set, save LLVM and Clang itself. Different people use their own favored projects to see how a warning fares.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>