(In reply to comment #253)
> (In reply to comment #252)
> > (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.
> 
> Kindly read comment #99.

Hopefully Linus has answered this one.

> > > 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,
> 
> Read the thread. No one has said any such thing. If you have experienced
> otherwise, please let us know.

I did read the thread, everybody mentioned 64-bit instead of "the square version", but Pablo Rodríguez mentioned he experiences the issue in 32-bit too. Anyway, I tried on my 32-bit laptop, and it doesn't seem to run, so I guess that's a different issue.

> > it's only a matter of time before the "square"
> > code gets into the "non-preview" version of Flash.
> 
> A hypothetical statement that makes a lot of assumptions about Adobe's
> development process. Do you work for Adobe?
> 
> They could also have committed a fix into their source tree months ago and its
> just a matter of time until they release a fixed version of the 64-bit plugin.
> 
> I don't work for Adobe and I don't see you with an @adobe.com email so my
> hypothetical statements are just as good as yours.

The 'square' plug-in is 10.3, and the current one is 10.2. If you don't put code in 10.3 beta that you would use in 10.3 final, what's the point of the beta then? Sure, maybe they fixed that internally, but maybe not.

> > 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.
> 
> If a tree falls in the woods...
> 
> > For more examples of issues, see:
> > http://lwn.net/Articles/414496/
> 
> Just read it, squashfs fixed their code, problem solved.

No, problem not solved. That's _one_ issue. Can you be certain that there are no issues lingering there? How many millions of line of code can be affected by this? Sure, we've found so far a few issues that were obvious, but there could be many more hidden, specially if they are subtle, or tricky to trigger.

> It also links to this:
> 
> http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278
> 
> "This patch includes optimized 64bit memcpy/memmove for Atom, Core 2 and
> Core i7.  It improves memcpy by up to 3X on Atom, up to 4X on Core 2 and
> up to 1X on Core i7.  It also improves memmove by up to 3X on Atom, up to
> 4X on Core 2 and up to 2X on Core i7."

So? memcpy can be improved, and so can memmove. But they are the same. So again, this potential breakage provides _zero_ gain.

> > So, not fixing this bug means silently breaking stuff with _zero_ gain.
> 
> Your "zero gain" premise is contradicted by at least two Intel engineers.
> 
> And Linus never said what hardware he was performance testing on, so we don't
> know that his testing contradicts the Intel engineers statements.

You are confused, don't mix two statements. What Intel guys said was that a memcpy _backwards_ is good on certain CPU's, that has _nothing_ to do with memcpy vs memmove.

> The Intel engineer in comment #99 even gave a credible technical explanation as
> to why it is faster to copy backwards, that makes sense if you know anything
> about modern processor designs. Presumably Intel understands how their own CPUs
> work.

Which has nothing to do with the issue at hand.

Anyway, here's the new bug to properly reflect what's causing this: bug #691336.