<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> 1) if (a = b) is very likely to be an error</div>
</div></div></blockquote><div><br></div><div>Fair enough - not the best example, I'll admit.</div><div><br></div><div>In the case of NULL/0 usage we agree that some uses of NULL in non-pointer contexts could be errors & we can help developers find bugs by suggesting that the thing they're using NULL on isn't really a pointer & since they used NULL we think they thought that they were talking about a pointer. Likely to be an error.<br>
<br>But once they start using 0 we don't know. Some developers deliberately use 0 when they mean "null pointer" but we can't guess when they meant to & when they didn't. If we suggest they use nullptr then we know & they'll get useful error messages when they intended to use a pointer & weren't actually using a pointer.</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>You're advocating a coding style that favors nullptr over 0. That's fine, and for a purely C++0x code base I *might* agree with you (although 0 is so much shorter than nullptr). However, the use of 0 rather than nullptr is not a good indication that there is actually a problem with the code, so we're outside the domain of what a compiler should do.</div>
</div></blockquote><div><br></div><div><br></div><div>That seems to me to be more than a stylistic issue - that's a "we're not sure what you intended here so you're not getting the helpful diagnostics you could be if you were providing more semantics to the compiler" (the helpful diagnostics we're already providing for nullptr and NULL usage where we know what you meant - so we already have precedent that shows these things are helpful/have some value).</div>
<div><br></div><div>I know GCC and Clang provide great diagnostics for NULL (could be better, we agree & we can fix that) and nullptr usage - but all the value of that is lost without any warning as soon as someone uses a 0 null pointer literal. Seems to very easily defeat the value we agree exists in those diagnostics.</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>Lots of code bases will be compiling both as C++98 and as C++0x for several years. I build Clang as C++0x with libc++; do you want me changing all of the 0's to nullptr's? The buildbots sure don't want me to.</div>
</div></div></blockquote><div><br></div><div>Indeed - in that case I think it'd be reasonable to suppress any warnings about "old" C++98 constructs that have better C++0x equivalents, such as nullptr. (I could still see having a warning that suggests NULL for pointer literals over 0, so as to help developers recognize when their intent differed from the reality of the code - in the "I want to build as C++0x and C++98" scenario then you'd suppress the nullptr warning, but you could leave the NULL mismatch warning on)</div>
<div><br></div><div>Of course I can try implementing this myself & running it on llvm/clang, though it'll be hard to say if it finds any bugs since replacing 0 with NULL won't tell me if the developer originally thought they were passing an integer parameter. I don't know all the code/call sites well enough to be able to judge that. But I would think going forward it could have value by telling the developer that what they thought was an integer parameter was really a pointer parameter (& perhaps they shouldn't be passing null, say).</div>
<div><br></div><div>This seems quite different from stylistic issues such as bracing, line length, naming, or even the other thread about boolean testability (which way should you test a null pointer: if (x), if(x == NULL), etc...).</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"><br><blockquote type="cite"><div><div><div><span style="font-family:arial, sans-serif;font-size:13px;background-color:rgb(255, 255, 255)"><div>
> For the other side of the equation, check out the warning + Fix-It for this code:</div></span><span style="font-family:arial, sans-serif;font-size:13px;white-space:pre-wrap;background-color:rgb(255, 255, 255)">> struct Point { int x, y; } p = { x: 10 };</span></div>
<div><font face="arial, sans-serif"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="arial, sans-serif"><span style="white-space:pre-wrap">I agree, this is a much more compelling warning than the one I'm proposing - and I'm sure there are many other better/less ambiguous warnings than nullptr. My point is that there are many /less/ compelling warnings too (though I don't know which of those are consistent with your philosophy & which aren't).</span></font></div>
<div><font face="arial, sans-serif"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="arial, sans-serif"><span style="white-space:pre-wrap">Side note:</span></font></div>
<div><span style="font-family:'Times New Roman';font-size:medium"><pre><span style="font-weight:bold">/tmp/webcompile/_1251_0.c:1:37: </span><span></span><span style="color:rgb(255, 0, 255);font-weight:bold">warning: </span><span></span><span style="font-weight:bold">use of GNU old-style field designator extension [-Wgnu-designator]
</span><span>struct Point { int x, y; } p = { x: 10 };
</span><span style="color:green;font-weight:bold"> ~~ ^
</span><span></span><span style="color:green"> .x = </span></pre></span></div><div>Shouldn't that ^ be below the x, not the 10? like this:</div>
<div><br></div><div><span style="font-family:'Times New Roman';font-size:medium"><pre><span style="font-weight:bold">/tmp/webcompile/_1251_0.c:1:37: </span><span></span><span style="color:rgb(255, 0, 255);font-weight:bold">warning: </span><span></span><span style="font-weight:bold">use of GNU old-style field designator extension [-Wgnu-designator]
</span><span>struct Point { int x, y; } p = { x: 10 };
</span><span style="color:green;font-weight:bold"> ^~
</span><span></span><span style="color:green"> .x = </span></pre></span></div></div></div></blockquote></div><div>Yes, that'd be better. Patch welcome :)</div></div></div></blockquote>
<div><br></div><div>Sent.</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"><div>It's easy to add diagnostic subgroups. -Wnull-arithmetic can be a subgroup of some new group covering NULL-as-integer warnings.</div>
</div></div></div></blockquote><div><br></div><div>Sounds good.</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"><div>I could live with suggesting nullptr in C++0x and NULL (if available) or 0 otherwise.</div></div></div></div></blockquote><div><br></div><div>Yep - and I've found some precedent for that in the uninitialized variable warning code (sent out a related fix there, too) - perhaps this code that decides on null pointer literals could be refactored out into some common location.</div>
<div><br></div><div>[as mentioned in the code review email, the logic that detects if NULL is defined is somewhat simplistic - I guess it takes into account the state of macros at the end of parsing of the file so if NULL is defined after the usage, it is still suggested (or if it's undefined later on, it is never suggested). But I guess that's OK. It hardly seems practical to fix 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">Well, you can compile LLVM and Clang as C++0x. </div>
</div></div></blockquote><div><br></div><div>Do you just set CXXFLAGS to -std=c++0x when you run make, then? I'll have to give that a go.</div><div><br></div><div>Thanks,</div><div>- David</div></div>