<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 01/04/2017 01:01 PM, James Y Knight
wrote:<br>
</div>
<blockquote
cite="mid:CAA2zVHoOJEcZvfipfN6gxxYxePRdar8V4XoDaffKAmUpPRfTsg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
Agreed. We should use the list to generate warnings, etc. regardless
of how the headers are annotated.<br>
<br>
-Hal<br>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>