Re: Support for memcpy with equal source and destination

[Ralf Jung <post@ralfj.de>]

Hi all,

> On 2023-11-25 00:20, Ralf Jung wrote:
>> For a memcpy that is implemented in C (rather than assembly), I don't think it 
>> is possible to make this promise (of supporting src==dest) when there is 
>> "restrict" in the signature.
> 
> Actually it is possible, though it costs a conditional branch compared to the 
> naive approach that generally would work anyway.

Ah, true, I forgot about that option.

However, at that point it seems unclear why that branch should live inside 
`memcpy`, rather than being performed by the caller. The entire argument made 
all along by compiler developers (as I understood it) was that the existing 
`memcpy` are already working fine for the src==dest case; if new branches need 
to be added, that's a different discussion.
This probably needs benchmark to determine on which side the branch is less 
expensive overall? Or a dedicated memcpy variant that allows src==dest, as has 
been brought up elsewhere.

> When n is zero, this implementation also supports NULL dest or src, though 
> that's a separate issue.

Yeah I'd like to see that guarantee as well, if possible. :)

Kind regards,
Ralf

> 
> 
>> when one sees restrict in a signature, it is impossible to tell what the 
>> actual constraint is without further documentation: the function needs to say 
>> which memory is being accesses through which pointer, and *that* is then where 
>> the disjointness comes from.
> 
> True, and one could document the new guarantee along those lines. Writing the 
> documentation could be a bit tricky, though, as one needs to explain all this 
> stuff clearly without being too prolix.
>