<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 09/01/2014 12:13, Chandler Carruth
wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0Kj51JcA3FtvwzMfdQXyC=0nPxHkdu7UrenSMuD155y7Tg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jan 9, 2014 at 4:07 AM, Alp
Toker <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">I understand that, but the question is
-- do you think that usage pattern will be prevalent?
Is it worth putting an external definition in the
binary *always* just to catch the case where we do a
link-time-only flag?<br>
<br>
Put another way, is it really too burdensome to say
that LSan does require a compile time flag in order to
support some usage patterns?<br>
</div>
</blockquote>
<br>
Who controls / defines the interface?<br>
</blockquote>
<div><br>
</div>
<div>The sanitizers.</div>
</div>
</div>
</div>
</blockquote>
<br>
Can you report a bug with them? They need to provide hooks that can
be implemented cleanly.<br>
<br>
It's not reasonable to force something like this on the entire
community just because your internal schedule demands it.<br>
<br>
There are plenty of other checkers and analyzers that work fine
without forcing problematic code, and that can be disabled without
impacting standard builds, so it's not a big problem for the
community if this takes a few days to get resolved out of tree.<br>
<br>
To be clear, the commits not only introduce dead code, but code that
actively causes build issues in strict setups because it's not
compliant with the C++ specification and steps on the reserved
namespace.<br>
<br>
Furthermore, the references I could find to this group of sanitizer
functions doesn't inspire confidence that they were thought through
as thoroughly as you suggest:<br>
<br>
<blockquote>kcc commented on this revision.<br>
I am actually <b>not a big fan of this patch</b>. <br>
We know <b>only one use case</b> for it, and I really hope we can
find a cleaner solution.<br>
<br>
samsonov requested changes to this revision.<br>
I agree with Kostya that <b>we should avoid adding this</b>
interface function if possible.<br>
</blockquote>
<br>
<blockquote
cite="mid:CAGCO0Kj51JcA3FtvwzMfdQXyC=0nPxHkdu7UrenSMuD155y7Tg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This looks like a spectacular thinko rather than being
something intentional -- is it possible to fix it to drop
one or more underscores instead of devising workarounds?<br>
</blockquote>
<div><br>
</div>
<div>I have no idea what you mean. This was a well
considered change, and part of a design that has been
developed over quite some time on the lists. None of these
are workarounds?</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There's never a valid reason to require user code to
define reserved names (although it's sometimes OK for user
code to _use_ reserved names).<br>
</blockquote>
<div><br>
</div>
<div>You keep making this assertion, but I still don't find
any backing for it in the standard. I'm happy to check
with some of my fellow members of the committee, but I
would be surprised if they drew the distinction you are
drawing here.</div>
</div>
</div>
</div>
</blockquote>
<br>
I'm not making an assertion. The standard is very clear on this:<br>
<br>
<br>
<blockquote><b>17.6.4.3 Reserved names [reserved.names]</b><br>
<br>
If a program declares or defines a name in a context where it is
reserved, other than as explicitly allowed by this Clause, its <b>behavior
is undefined</b>.<br>
<br>
<b>17.6.4.3.2 Global names [global.names]</b><br>
<br>
Certain sets of names and function signatures are always reserved
to the implementation:<br>
<br>
<ul>
<li><b>Each name that contains a double underscore __</b> or
begins with an underscore followed by an uppercase letter
(2.12) <b>is reserved to the implementation for any use</b>.</li>
<li>Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.</li>
</ul>
</blockquote>
<br>
<br>
<blockquote
cite="mid:CAGCO0Kj51JcA3FtvwzMfdQXyC=0nPxHkdu7UrenSMuD155y7Tg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm heading out for a couple of hours, please gate this
behind a macro or revert until a resolution is found.</blockquote>
</div>
<br>
Alp, I really don't think this is reasonable. This change, and
the lead up to the change, were discussed on the list with
code review. I understand you have some high level design
concerns, but there doesn't appear to be broad agreement with
them and I don't think it is reasonable to block progress here
while we sort them out.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I'm happy to continue this discussion,
but I do not think that this needs to be reverted, and I do
not think we need to block progress</div>
</div>
</blockquote>
<br>
I've just discussed with colleagues as well as a clang frontend
developer (all of whom are pretty keyed in on the matter) and
there's broad agreement that these changes are not wanted in their
current form.<br>
<br>
Moreover, it's blocking work on a practical level by triggering
legitimate build issues in at least one configuration. Removing the
function doesn't break anything and resolves the issues. I don't see
the problem here?<br>
<br>
Anyway, I'm returning to the office to deal with this and I'm
disappointed you've tried to push it through unilaterally with
disregard for anyone outside of your own circle.<br>
<br>
Alp.<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.nuanti.com">http://www.nuanti.com</a>
the browser experts
</pre>
</body>
</html>