On Thu, Aug 13, 2015 at 4:53 PM, Stephen Hines via cfe-commits <cfe-commits@lists.llvm.org> wrote: > 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.
7.24.1p2 (in part): Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. 7.1.4p1 (in part): If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined. While memcpy isn't a function with a variable number of arguments, I believe the "as described in 7.1.4" is referring to the description of invalid values. The fact that it is a shall clause in 7.24.1 means that violation results in undefined behavior. At least, that is my interpretation of the standard. ~Aaron > > 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 > _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
