Discussed some time ago here: https://reviews.llvm.org/D53342 , the conclusion was to stay conservative - assume nothing about pointers if size could be zero - and according to the previous decision, memcpy(nullptr, nullptr, 0) is fine, indeed. But is is not:
c99: 7.21.2.1 "The memcpy function copies n characters from the object pointed to by s2 into the
object pointed to by s1. If copying takes place between objects that overlap, the behavior
is undefined."
null is not a pointer to an object
So even when size is zero, pointer(s) must be valid.
Somebody may say that even if this is UB, it works in practise. Not at all:
urnathan: (For amusement value, I do know MIPS' memcpy routines segfault on memcpy (dst, nullptr, 0))
Maybe we can reevaluate previous decision now?
If this rule is broken, UBSan catches this UB without any problems, as recently shown in: https://reviews.llvm.org/D124524 / https://godbolt.org/z/qx4sK43f6
It seems that for a bool the default ought to true rather than 1 (ditto for the actual argument at the call sites); a better name for the argument would also reflect the fact it's a toggle rather than a count.
But I wonder if changing the last argument to something like Value *MinBytes = nullptr and computing the Boolean result from it here would be a way to simplify the code and avoid having to do that at the call site.