<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">
<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><div>I have already expressed my reasons for not wanting to introduce yet more off-by-default warnings.</div></div></div></blockquote><div><br></div><div>Right - my point was this seems like a counterargument to that, showing a good use case for an off-by-default warning.</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>
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><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. </div></div></div></blockquote>
<div><br></div><div>Yet we already agree that there's practical benefits to this - that we only get half of. Anyone using 0 everywhere gets nothing, but if people err on the side of NULL they get something but without much of a guarantee that they haven't accidentally slipped in a 0 somewhere. 'spose that's not so different from bracing, though - "hey, brace every block & you'll be less likely to get bugs over dangling elses, but the compiler won't check that you haven't accidentally snuck in an unbraced block".</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>That's not relevant here: the convention is not widespread enough to codify it in a compiler.</div>
</div></div></blockquote><div><br></div><div>That was my point about -Wparentheses. In that case the only way it got codified was by its inclusion in the compiler. I doubt many people had that as an existing practice prior to that.</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>Hence the use of a style checker, which presumably will get run often.</div>
</div></div></blockquote><div><br></div><div>Yep. I'll certainly have a go at that.</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>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></div></div></blockquote><div><br></div><div>Noted.</div><div><br></div><div>I'll have a go at the "don't use NULL in non-pointer contexts" fix at some point, at least.</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>IIRC, it does have Fix-Its on the notes.</div></div></div></div></blockquote><div><br></div><div>Oh, so it does - not sure how I missed that. But that does answer one of my previous questions - it is possible to have multiple fixits variations presented to the user, they just have to be presented in notes, not both in the same diagnostic message itself. Good to know.</div>
<div><br>- David</div></div>