Comment 297 for bug 727064

(In reply to comment #248)
> If you don't want the burden of choosing correctness over speed, don't program
> in C.

Have you measured the speed difference between memcpy and memmove? No? Then don't assert that one is faster than the other, because they aren't. This has been demonstrated in the thread with numbers.

> Does anyone read the thread? Flash works fine, its only people insisting on
> using an unsupported (by Adobe themselves) 64-bit preview version of flash
> having a problem.

AFAIK it happens on 32-bit too, it's only a matter of time before the "square" code gets into the "non-preview" version of Flash.

Anyway, this bug is _not_ about Flash, it's about glibc. Anything that uses memcpy can be affected silently. How much code is misbehaving thanks to this change? It's impossible to know.

For more examples of issues, see:
http://lwn.net/Articles/414496/

So, not fixing this bug means silently breaking stuff with _zero_ gain.

Now, can we rename this bug to:
"memcpy acts randomly (and differently) with overlapping areas"

Or shall I create a new one and make this one depend on that?