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.li...@gmail.com> wrote: > >> On Wed, Aug 12, 2015 at 4:03 PM, Dan Albert <danalb...@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 > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
