[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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Ralf Jung from comment #0)
> 
> My assumption is that this only requires a change to the documentation, and
> that the implementation is already well-defined for to==from. If, however,
> the implementation of glibc on some targets is *not* producing well-defined
> results for to==from, then that would also be very interesting to know.

From the draft proposal document [1], it means that memcpy and other
string/memory functions might accept NULL/invalid arguments. 

It would require glibc to remove the __nonnull on various prototypes and check
if the compiler builtin used on fortify would also handle NULL pointers
correctly.  It would require extending both default and fortify testing, and
adding appropriate support if required (on fortify wrappers for instance if
there are compiler bugs). 

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).

The PowerPC dcbz trick is not used on powerpc optimization, and cache fill
instructions are only used on memset implementations (and for zero fill, so I
don't think this would be an issue).

[1]
https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UCPyZOTLsnRfR6UleD1F8/edit

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