<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 2:41 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jan 9, 2014 at 2:29 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we're going to back out the revert, can we put the code into an<br>
#ifdef so that the reserved namespace identifier is protected when<br>
compiling with something that doesn't understand lsan? Then we can<br>
argue over the "right" way with some protection.</blockquote><div><br></div></div><div>I'm not opposed to that, if we have a suitable predefine. But we already have *loads* of code in Clang that defines identifiers in the reserved namespace (try grepping for '[A-Za-z]__[A-Za-z]' in include/ to find a bunch of them), and none of our supported C++ implementations (for clang 3.5) have a problem with this, so I don't see that there's a lot of value in doing so.</div>
</blockquote></div><br>Further, I don't think we should slow down the efforts to get LSan bootstrapping effectively while we figure out the correct predefine -- we can add one later as the discussion converges. That had been my plan from the beginning.</div>
</div>