<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 12:54 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<p><br>
</p>
<div class="gmail-m_-8933751235465522172moz-cite-prefix">On 01/04/2017 11:43 AM, James Y Knight
via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Jan 4, 2017 at 11:12 AM,
Aaron Ballman via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-m_-8933751235465522172gmail-HOEnZb">
<div class="gmail-m_-8933751235465522172gmail-h5">So I would be opposed to ignoring
those attributes in<br>
</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Sema (I think we should still warn when users do
nonportable things),<br>
but in favor of not changing the optimizer to capitalize
on this<br>
"opportunity."<br>
</blockquote>
<div><br>
</div>
<div>I'd be opposed to ignoring the attributes only in some
places and not in others. It should be ignored totally, as
if it wasn't present on those functions. Doing anything
else sends the wrong message -- that libc authors should
continue to use nonnull on these functions because they
might be helpful, and won't do anything bad.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
I think that we have a responsibility to our users to continue to
warn (statically, in ubsan, etc.) on non-portable behavior, which
this is and will continue to be in practice for at least a decade or
two, regardless of the message we'd like to send libc authors. We
cannot undo history here and this will be relevant to production
systems for at least a decade. We can talk to libc developers
directly -- they're a much smaller set -- and we can pursue change
at the standards level while still providing the most useful set of
tools to our users in the mean time.</div></blockquote><div> </div><div>But, this is an entirely different question.</div><div><br></div><div>- Should clang warn about non-portable usage of passing NULL to memcpy/etc?</div><div><br></div><div>Sounds like a fine warning to add.</div><div><br></div><div>- Should that warning be dependent on the libc headers having nonnull annotations on these functions, which will be used only for warnings, and ignored for semantics, on this given list of hardcoded functions?</div><div><br></div><div>No.</div><div><br></div><div>Firstly: I'd note that nearly all libc implementations don't use these attributes today. In some cases, because they've simply not thought about it, but in others because they explicitly decided to NOT break their users' code by introducing this problem! Glibc is the outlier, here. </div><div><br></div><div>So: what portability do you want to warn for? Portability assuming the same libc, but a different compiler which might fail to ignore the nonnull attribute? Or portability to other libc? If the latter, depending on the nonnull attribute being present doesn't and can't work.</div><div><br></div><div>Secondly: if we already have a hardcoded list of functions to special case, that could just as well be used to generate a nonportable-stringfunc-null warning, as well.</div><div><br></div></div></div></div>