[PATCH] D11948: Add some macros to abstract marking of parameters as "not null", and use them in <cstring>

[Aaron Ballman via cfe-commits]

On Thu, Aug 13, 2015 at 4:53 PM, Stephen Hines via cfe-commits
<cfe-commits at 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 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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>