<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 9, 2011, at 10:51 PM, David Blaikie wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Wed, Sep 7, 2011 at 3:29 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div style="word-wrap:break-word"><br><div><div><div>On Aug 30, 2011, at 7:37 PM, David Blaikie wrote:</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
> 2) adds a fixup for this warning in C++0x to suggest using nullptr<br>
><br>
> I think there's still a bunch of things worth discussing about when to<br>
> suggest nullptr and what to suggest in C++98 (0, NULL, nothing at<br>
> all?) & I'd like to apply this kind of suggestion/fixup in a much more<br>
> general way (to all null pointer literals that aren't nullptr, not<br>
> just the false boolean literal) - but I thought this might be a<br>
> moderately easy experiment, even if it's throwaway, and might be a<br>
> more concrete thing to start such discussions.<br>
<br>
<br>
</div>Seems like we should suggest nullptr, NULL, or 0, depending on which dialect we're in, as we've done elsewhere.<br></blockquote><div><br></div><div>Agreed - I hadn't seen the smarts to do this when I sent this patch out, & I stumbled across it in the uninitialized variable case afterwards. <br>
<br>I've put a public utility function in Sema to produce a StringRef of the appropriate null pointer literal & used that in both cases.</div></div></blockquote></div><div><br></div></div><div><div><blockquote type="cite">
<div class="gmail_quote"><div>Looking at other similar cases I came across a case in ~line 250, SemaExpr.cpp - handling missing null sentinel nodes (in ObjC/C++ I assume). I don't fully understand the last case there, though - that chooses between "0" and "0L". Also, this seems inconsistent with the (matching) null case in SemaCodeComplete.cpp which suggests "nil", "NULL", or "(void*)0".<br>
</div></div></blockquote><div><br></div></div><div>Ick. The reason for 0L is that, when we're dealing with C-style varargs, we need to make sure that the 0 value we suggest is the same length as a pointer. It would be good to give getNullPointerLiteral() the ability to produce 0L when needed, perhaps with a configuration option.</div>
</div></div></blockquote><div><br></div><div>Oh, tricky. In that case we can't reliably suggest a non-macro null pointer literal then, can we? Because then the code would be non-portable between 64 and 32 bit (etc) builds. <br>
<br>That sort of leaves the (void*)0 as the 'right' solution for a portable, size-appropriate, non-macro'd, non-C++0x literal. Or is there another way?</div></div></blockquote><div><br></div><div>I don't know of any other way. When we're dealing with sentinels, (void*)0 is a fine fallback.</div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></div></body></html>