<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 12:49 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">OK, sorry I only just got round to this. Backed out in r198884 and r198885.<br>
<br>
In principle it's OK to re-land this with the ifdef Jordan suggested, but I think it'd be more sustainable to try using non-reserved identifiers for the library part of the sanitizer interface if you have time to look into that.<br>
</blockquote><div><br></div><div>I'm not sure if you're aware of this Alp, but using a reserved "weak" symbol is a classic and widely used way to expose "hooks" into runtime libraries/instrumentation.</div>
<div><br></div><div><a href="http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html">http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html</a><br></div><div><a href="http://msdn.microsoft.com/en-us/library/c63a9b7h.aspx">http://msdn.microsoft.com/en-us/library/c63a9b7h.aspx</a><br>
</div><div>__libc_malloc_dispatch in bionic libc</div><div><br></div><div>The alternative is usually a function called by the user code in main() or whatever, which takes a function pointer.</div><div><br></div><div><br></div>
<div>-- Sean Silva</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">
<br>
Cheers<br>
Alp.<br>
<br>
<br>
<br>
On 09/01/2014 17:52, Jordan Rose 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 Jan 9, 2014, at 9:42 , 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>
</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"><div class="im">
<br>
On 09/01/2014 17:30, Jordan Rose wrote:<br>
</div><div><div class="h5"><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 Jan 9, 2014, at 6:57 , 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>><<u></u>mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<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">
I'm not making an assertion. The standard is very clear on this:<br>
<br>
<br>
*17.6.4.3 Reserved names [reserved.names]*<br>
<br>
If a program declares or defines a name in a context where it is<br>
reserved, other than as explicitly allowed by this Clause, its<br>
*behavior is undefined*.<br>
<br>
*17.6.4.3.2 Global names [global.names]*<br>
<br>
Certain sets of names and function signatures are always reserved<br>
to the implementation:<br>
<br>
* *Each name that contains a double underscore __*or begins<br>
with an underscore followed by an uppercase letter (2.12) *is<br>
reserved to the implementation for any use*.<br>
* Each name that begins with an underscore is reserved to the<br>
implementation for use as a name in the global namespace.<br>
<br>
<br>
</blockquote>
<br>
I know I shouldn't be getting into this, but...<br>
<br>
*1.3.24 undefined behavior [defns.undefined]*<br>
behavior for which this International Standard imposes no requirements<br>
/[ Note: Undefined behavior may be expected when this<br>
International Standard omits any explicit definition of behavior<br>
or when a program uses an erroneous construct or erroneous data.<br>
*Permissible undefined behavior* ranges from ignoring the<br>
situation completely with unpredictable results, *to behaving<br>
during translation or program execution in a documented manner<br>
characteristic of the environment* (with or without the issuance<br>
of a diagnostic message), to terminating a translation or<br>
execution (with the issuance of a diagnostic message). Many<br>
erroneous program constructs do not engender undefined<br>
behavior; they are required to be diagnosed. — end note ]/<br>
<br>
<br>
(emphasis mine)<br>
<br>
As I read this, a valid interpretation of this program is that when LEAK_SANITIZER is defined, the program contains undefined behavior, and therefore it should only be set in a context when the particular implementation is known to do something sensible for this particular undefined behavior (that is, use the function at runtime to disable leak checking).<br>
<br>
I don't see this as abstractly different from the standard-specified practice of replacing the global operator new, so I don't think it's inherently an anti-pattern. I think everyone agrees on this since you've said already you'd have no objections if the name weren't one of the restricted [global.names] names.<br>
<br>
Would it help if the function were pre-declared in a system header, and then just implemented or not implemented in user code?<br>
</blockquote>
<br>
Hi Jordan,<br>
<br>
That's the current situation -- as long as sanitizer headers are available and in use the part of the spec you highlighted means it's acceptable.<br>
<br>
The problem arises when sanitizer headers aren't available.<br>
</div></div></blockquote><div><div class="h5">
<br>
I just don't think the program is illegal when LEAK_SANITIZER is not defined. The tokens within the #ifdef are skipped completely, so they don't refer to names and certainly don't declare anything.<br>
<br></div></div>
I'm not sure we should care about the case where LEAK_SANITIZER is defined in an environment that doesn't specify what defining this particular name will do. The user has full control over this. (And in fact, IIRC being able to define macros on the command line isn't at all specified by the standard, so the program by itself will /always/ skip the LEAK_SANITIZER block.)<br>
<br>
Jordan<br>
<br>
</blockquote><div class=""><div class="h5">
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
______________________________<u></u>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>