[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:       Dan Albert via cfe-commits <cfe-commits () lists ! llvm ! org>
Date:       2015-08-13 20:47:36
Message-ID: CAFVaGhus-OeYT-37iRxER1EU864wczuoyinVWTT4np1MWkq+Qw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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
>
>
>

[Attachment #5 (text/html)]

<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 class="gmail_quote">On Aug \
13, 2015 07:16, &quot;Marshall Clow&quot; &lt;<a href="mailto:mclow.lists@gmail.com" \
target="_blank">mclow.lists@gmail.com</a>&gt; 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">&lt;<a href="mailto:danalbert@google.com" \
target="_blank">danalbert@google.com</a>&gt;</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&#39;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>


[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]