[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-commits
Subject: Re: [PATCH] D11948: Add some macros to abstract marking of parameters as "not null", and use them in
From: Stephen Hines via cfe-commits <cfe-commits () lists ! llvm ! org>
Date: 2015-08-13 20:53:02
Message-ID: CAAzmS6947ue+fdomu1RoNKj0qjVpW_VDjwr_yFC1Xo106c+37A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I don't see anywhere in the C standard that says that a memcpy() with NULL
for either pointer is UB (which would only be valid for the case where n ==
0). This seems like a particularly aggressive (mis)optimization in the
general case. It should only be acceptable if the length is guaranteed to
be nonzero. That doesn't seem to be how the optimizers work today,
unfortunately.
Steve
On Thu, Aug 13, 2015 at 1:47 PM, Dan Albert via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Because we consider the fact that clang and gcc do this when those
> functions are not marked with nonnull by the libc to be a bug. Adding it to
> libc++ would just make another place that we have to fix that bug.
>
> What is the objection to using _Nullable instead of
> __attribute__(nonnull)? The original motivation in the PSA for this was for
> better ubsan diagnostics. _Nullable does that for us, and leaves the
> decision of whether null is allowed up to the libc implementers (assuming
> the compilers are fixed).
> On Aug 13, 2015 07:16, "Marshall Clow" <mclow.lists@gmail.com> wrote:
>
>> On Wed, Aug 12, 2015 at 4:03 PM, Dan Albert <danalbert@google.com> wrote:
>>
>>> My testing was varied. I could not get GCC or clang to optimize it away
>>> for Linux, but both did for ARM Android.
>>>
>>
>> Then I don't understand your objection to this change, then.
>>
>> On your platform, the effect of this change is (therefore) a compile-time
>> warning when you pass (a constant) NULL to a set of functions that are
>> documented to require non-null parameters.
>>
>> -- Marshall
>>
>>
>>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
[Attachment #5 (text/html)]
<div dir="ltr">I don't see anywhere in the C standard that says that a memcpy() \
with NULL for either pointer is UB (which would only be valid for the case where n == \
0). This seems like a particularly aggressive (mis)optimization in the general case. \
It should only be acceptable if the length is guaranteed to be nonzero. That \
doesn't seem to be how the optimizers work today, \
unfortunately.<div><br></div><div>Steve</div></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Thu, Aug 13, 2015 at 1:47 PM, Dan Albert via cfe-commits <span \
dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" \
target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">Because we consider the fact that \
clang and gcc do this when those functions are not marked with nonnull by the libc to \
be a bug. Adding it to libc++ would just make another place that we have to fix that \
bug.</p><p>What is the objection to using _Nullable instead of \
__attribute__(nonnull)? The original motivation in the PSA for this was for better \
ubsan diagnostics. _Nullable does that for us, and leaves the decision of whether \
null is allowed up to the libc implementers (assuming the compilers are \
fixed).</p><div><div class="h5"> <div class="gmail_quote">On Aug 13, 2015 07:16, \
"Marshall Clow" <<a href="mailto:mclow.lists@gmail.com" \
target="_blank">mclow.lists@gmail.com</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_extra"><div class="gmail_quote">On Wed, Aug 12, 2015 at 4:03 PM, Dan \
Albert <span dir="ltr"><<a href="mailto:danalbert@google.com" \
target="_blank">danalbert@google.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">My testing was varied. I could not get GCC or \
clang to optimize it away for Linux, but both did for ARM \
Android.</div></blockquote><div><br></div><div>Then I don't understand your \
objection to this change, then. </div><div><br></div><div>On your platform, the \
effect of this change is (therefore) a compile-time warning when you pass (a \
constant) NULL to a set of functions that are documented to require non-null \
parameters. <br></div><div><br></div><div>-- \
Marshall</div><div><br></div><div><br></div></div></div></div> </blockquote></div>
</div></div></div>
<br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" \
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br> \
<br></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic