<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 8:03 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On 09/01/2014 15:23, Kostya Serebryany wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
On Thu, Jan 9, 2014 at 6:57 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
<br>
On 09/01/2014 12:13, Chandler Carruth wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Who controls / defines the interface?<br>
<br>
<br>
The sanitizers.<br>
</blockquote>
<br>
Can you report a bug with them?<br>
<br>
<br>
That's us (no need to file a separate bug unless you want to)<br>
</div></blockquote>
<br>
That's fantastic. A proper resolution might be in sight in that case..<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
Moreover, it's blocking work on a practical level by triggering<br>
legitimate build issues in at least one configuration. Removing<br>
the function doesn't break anything and resolves the issues. I<br>
don't see the problem here?<br>
<br>
<br>
Will you get unblocked if we put this code under #ifdef LEAK_SANITIZER ?<br>
Alternatively you may probably build the code with -D__lsan_is_turned_off=<u></u>something_else<br>
</blockquote>
<br></div>
If conditionalizing turns out to be necessary, it seems best to not to enable the function definition unless it's explicitly leak sanitizer build.<br>
<br>
However I'm starting to understand what you were trying to achieve and have a much better proposal below..<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Do you have suggestions how to improve the interface<br>
</blockquote>
<br></div>
We should be able to find a name or mechanisms to do this properly, given that you have control over the interface. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
w/o risking to clash with user-defined names?<br>
</blockquote>
<br></div>
That right there appears to be the point of confusion.<br>
<br>
The problem is that you've required users to declare a function name that should have been reserved for the implementation.<br>
<br>
I said earlier this appears to be a "thinko" in the sanitizer interface. I said that because, for the majority of sanitizer functions, you're dealing with the reverse problem, and that appears to have leaked into the naming of these functions unintentionally.<br>
<br>
So it's not a question of avoiding a clash with user-defined names, but the other way round.<br>
<br>
In summary, the problem you need to solve is identical to the naming choices when declaring an entry point in a public C programming interface.<br>
<br>
Try naming this like any C API function (which is what it is) and you'll have a solution. Some good LLVM-style function name conventions are "include/llvm-c/Core.h" assuming you want to go with the LLVM CamelCase style.<br>
<br>
With this approach, you have the same risk of conflict as any C function, which is a well-understood problem space. The sanitizer is then free to give this symbol name special handling internally without imposing on others.<br>
<br>
If you do this there's no need to conditionalize, but please retain the comment explaining the purpose so it doesn't get "cleaned up".<br>
<br>
Thanks for inviting a discussion Kostya. Does that sound good to you?</blockquote><div><br></div><div>So, you propose to name this function lsan_is_turned_off (or some such) instead of __lsan_is_turned_off?</div><div>That will work, but then there is a non-zero chance that a user will already have such function for whatever purposes of his own.</div>
<div>What's worth, he will not know about the clash at the link time -- his program will start behaving wrongly.</div><div>The __ prefix is exactly the tool that allows us to avoid a clash with user-named objects.<br>
</div><div>Or I've got you wrong? </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
<br>
Alp.</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
--kcc<br>
<br>
<br>
Anyway, I'm returning to the office to deal with this and I'm<br>
disappointed you've tried to push it through unilaterally with<br>
disregard for anyone outside of your own circle.<br>
<br>
<br>
Alp.<br>
<br>
-- <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
<br>
</blockquote>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div></div>