llvm dev - Jul 2017 - Which assumptions do llvm.memcpy/memmove/memset.* make when the count is 0?

> So, the pointer arguments of memcpy *shall* (a violation of a shall 
> clause is UB, per §4/2) have valid values, even though the function will 
> copy zero characters.
This is true in C but the question was about LLVM intrinsics.

Since the LangRef does not mention any such restriction, I would assume 
that memcpy(0,0,0) is not UB in LLVM.  If it is UB then we must update 
the LangRef to be clear on this point (actually we should update the 
LangRef either way since this is a question that'll come up again).

John

Also note that whereas GCC exploits the tricky definition of memcpy(), 
LLVM at present doesn't appear to:

   https://godbolt.org/g/8uxvBQ

In fact LLVM doesn't even assume the pointer is non-null in a case where 
I'd argue that it should:

   https://godbolt.org/g/svHQKL

John


On 07/20/2017 10:00 PM, John Regehr via llvm-dev wrote:
>> So, the pointer arguments of memcpy *shall* (a violation of a shall 
>> clause is UB, per §4/2) have valid values, even though the function 
>> will copy zero characters.
> 
> This is true in C but the question was about LLVM intrinsics.
> 
> Since the LangRef does not mention any such restriction, I would assume 
> that memcpy(0,0,0) is not UB in LLVM.  If it is UB then we must update 
> the LangRef to be clear on this point (actually we should update the 
> LangRef either way since this is a question that'll come up again).
> 
> John
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

As of earlier this year, we now explicitly ignore the nonnull
attributes that glibc puts on memcpy (and other stdlib functions). I
don't know how LLVM feels about dangling or underaligned pointers in
particular, but AFAICT, we do try hard to make sure that
memcpy(NULL, _, 0) works as the user probably intends.

Here's the thread I read about it:
http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html . As
I recall, the tl;dr was "optimizing these assumptions to death doesn't
realistically buy us much of anything, and there's a nontrivial amount
of real-world code that depends on this behavior."

On Thu, Jul 20, 2017 at 9:06 PM, John Regehr via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Also note that whereas GCC exploits the tricky definition of memcpy(), LLVM
> at present doesn't appear to:
>
>   https://godbolt.org/g/8uxvBQ
>
> In fact LLVM doesn't even assume the pointer is non-null in a case
where I'd
> argue that it should:
>
>   https://godbolt.org/g/svHQKL
>
> John
>
>
>
> On 07/20/2017 10:00 PM, John Regehr via llvm-dev wrote:
>>>
>>> So, the pointer arguments of memcpy *shall* (a violation of a shall
>>> clause is UB, per §4/2) have valid values, even though the function
will
>>> copy zero characters.
>>
>>
>> This is true in C but the question was about LLVM intrinsics.
>>
>> Since the LangRef does not mention any such restriction, I would assume
>> that memcpy(0,0,0) is not UB in LLVM.  If it is UB then we must update
the
>> LangRef to be clear on this point (actually we should update the
LangRef
>> either way since this is a question that'll come up again).
>>
>> John
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev