[PATCH] D11948: Add some macros to abstract marking of parameters as "not null", and use them in <cstring>
Stephen Hines via cfe-commits
cfe-commits at lists.llvm.org
Thu Aug 13 13:53:02 PDT 2015
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,
On Thu, Aug 13, 2015 at 1:47 PM, Dan Albert via cfe-commits <
cfe-commits at 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 at gmail.com> wrote:
>> On Wed, Aug 12, 2015 at 4:03 PM, Dan Albert <danalbert at 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 at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits