© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
(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.