<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 4:18 PM, 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"><div>We're going in circles. I think we agree that preferring nullptr to 0:</div>
</div><div><br></div><div> (1) May prevent some mistakes arising from confusion between 0 being both an integer value and a null pointer , and</div><div> (2) Is not in widespread use in C++ code today.</div><div><br></div>
<div>Your suggested warning about the use of 0 in a pointer context only makes sense if a particular code base follows this convention to start with, or the user wants to establish this convention. The former case is too rare now to consider (per (2)),</div>
</div></div></blockquote><div><br></div><div>Doesn't that make a perfect case for an off-by-default warning, then? Rather than users having to employ a separate tool (though, I admit, if a clang plugin is easy/lightweight enough I'm not at all averse to doing this sort of thing as a plugin. I'll certainly follow up on that) to ensure they don't make such mistakes.<br></div></div></blockquote><div><br></div><div>I have already expressed my reasons for not wanting to introduce yet more off-by-default warnings.</div><br><blockquote type="cite"><div class="gmail_quote"><div>It does seem a pity that even new C++ code would suffer the ills of old C++ code because the compiler is being overly cautious about existing code (that would be fairly easy to fix up in the case where someone is actually using C++0x features in their code already, and suppressed if they're just looking to ensure their code compiles as both C++98 and C++0x). Perpetrating more pointer mistakes even after features designed to help developers here have been standardized.</div></div></blockquote><div><br></div><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>and the latter case is a style-checking issue that should not be a compiler warning.</div>
</div></div></blockquote><div><br></div><div>The point I'm making is that it's more than style - it has practical benefits that the compiler can understand the developers intent & provide diagnostics. How does the user know they're missing out on those useful diagnostics? Even if they know the diagnostics exist, it'll catch all their spurious NULL usage, but not the other way around (0 as null pointer) - that will be silently accepted without the use of an external tool.</div></div></blockquote><div><br></div><div>Every purveyor of a convention claims that it's more than style, and it has practical benefits if only developers would follow that convention. That's not relevant here: the convention is not widespread enough to codify it in a compiler.</div><div><br></div><div>If you consider this convention to be important, by all means write a style checker and evangelize the convention. Convert the masses, and they'll come banging on our door for compiler support.</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 class="im"><div>Clang's purpose is not to migrate code from C++98 to C++0x. That's a separate tool one could build with Clang.</div>
</div></div></div></blockquote><div><br></div><div>Even once migrated, the user still has the ongoing risk of a 0 instead of nullptr & then clang's helpful diagnostics are silently suppressed. </div></div></blockquote><div><br></div>Hence the use of a style checker, which presumably will get run often.<br><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 class="im">This is what one has to do to introduce a warning: implement it and see what the fallout is. With this warning, you're extremely likely to get an extremely low signal/noise ratio, especially because some coding standards actively encourage the use of 0 over NULL.</div>
</div></div></blockquote><div><br></div><div>Indeed - and I assume the parentheses warning had a low signal to noise ratio when it was first introduced too (that was more my point of giving the example). People had to transform all their existing code to conform to the pattern first (easy with clang, harder doing it manually with GCC) and from then on the diagnostic would help them.<br></div></div></blockquote><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>Granted, parentheses probably had a higher s/n ratio than this warning would have. Assignments in conditionals are rare & the chance of misuse is higher, but still over a lot of code I'm sure there's a lot of legitimate usage that had to be fixed up when this warning was introduced, and all without the convenience of clang fixits. </div></div></blockquote><div><br></div>Yes, these are among the reasons why -Wparentheses makes sense for Clang but complaining about 0 in a pointer context does not. In any case, my decision stands: we will not accept a warning about '0' being used in a pointer context at this time.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Hmm: should the parentheses warning offer a fixit to add parens? It's already suggesting as much in text.</div></div></blockquote><div><br></div>IIRC, it does have Fix-Its on the notes.<br><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>