[Bug string/31055] Request: guarantee that memcpy(x, x, n) is well-defined

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31055

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Ralf Jung from comment #2)
> > From the draft proposal document [1], it means that memcpy and other string/memory functions might accept NULL/invalid arguments. 
> 
> Yes, that too. Though I opened this issue specifically about the src==dest
> case.

I think with this extra constraint we can't really mark the memcpy as having
'restrict' arguments, which would also have extra performance implications.  It
would also mean deviating from C standard which I am not sure would be really
the correct approach.

(I may be reading the restrict keyword definition wrongly, and thus the C
standard does allow restrict with a pointer to alias to itself).

> 
> > I am also not sure if *all* the architecture memcpy implementation handles memcpy(x, x, n) correctly, although I expect it would not be an issue (GCC is already generating code with this assumption).
> 
> That's the thing. Either they fail for that case and we have a problem since
> GCC (and clang and rustc) generate bad code. Or they are all fine for that
> case and de-facto they can't change that anyway because GCC (and clang and
> rustc) rely on it, and it's better to just officially document this rather
> than continue with this annoying situation where something's clearly broken
> but nobody wants to fix it.

My understanding is if the compiler can not ensure the memory ranges don't
overlap, it should emit a memmove instead. But this is really a corner case
that won't really trigger the wrong result because afaiu all glibc memcpy
implementations do not issue any tricks as the powerpc one valgrind described.

> 
> (And this issue is not purely theoretical, it leads to real problems such as
> https://bugs.kde.org/show_bug.cgi?id=148543. The valgrind devs are waiting
> for *someone* to clarify what the contract for memcpy actually is.)

And I think valgrind will need to at least keep this warning for non-glibc
targets, which I am not it would simplify things.  Maybe the best way would to
follow the __memcmpeq route, where it was added solely for compile usage.

[1] https://sourceware.org/pipermail/libc-alpha/2021-September/131099.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.