[llvm-dev] Which assumptions do llvm.memcpy/memmove/memset.* make when the count is 0?
George Burgess IV via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 20 23:27:35 PDT 2017
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:
> In fact LLVM doesn't even assume the pointer is non-null in a case where I'd
> argue that it should:
> 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).
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev