[Bug libc/12518] memcpy acts randomly (and differently) with overlapping areas

["torvalds@linux-foundation.org" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12518

--- Comment #10 from Linus Torvalds <torvalds@linux-foundation.org> 2011-03-04 23:53:36 UTC ---
(In reply to comment #9)
> 
> It solves everything.  If you just relink without retesting you're an idiot and
> acting irresponsible.

It does solve a lot, and at least fixes the "you broke stuff that used to work"
issue.

However, I still don't understand why you guys can't just admit that you might
as well just do memmove() and be done with it. It's not slower. And the excuse
that "you'll have more implementations in the future" is just an even stronger
reason to do that.

To make this very clear: your new "and improved" memcpy() ACTS DIFFERENTLY ON
DIFFERENT MACHINES. That means that all that testing that was done by the
developer at link-time is ALMOST TOTALLY WORTHLESS, because what was tested
wasn't necessarily at all what the user sees.

I really don't understand why you can't admit that random behavior like that by
a very fundamental core library routine is actually a real problem. 

And there really isn't any upside. The optimized routines up to 80 bytes are
the same (in fact, my patch should speed them up by a few cycles), and anything
bigger than that will not notice the extra couple of cycles to check for
overlap.

So while I agree that it's a fix to the immediate problem to just say "don't
screw up for existing binaries", I do NOT understand why the glibc people then
apparently think it's fine to be stupid for new binaries.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.