

Glibc change exposing bugs (or how memcpy can bite you back) - madhouse
http://lwn.net/Articles/414467/

======
maximilianburke
The response of the developer (Andreas Schwab) is one of the most
unprofessional I've seen in a very long time, but then I have a particular
loathing for bugs that manifest as subtle runtime peculiarities. Technically
he's correct in that it's not a bug if you were to follow the letter of the
(API) law but to break existing functionality at such a fundamental layer and
then say "hey, not my problem!" blows me away.

I'm not quite sure how I would handle it in a project as large as glibc but if
this was my project I'd probably provide a fast_nonoverlapping_memcpy that did
all the neat platform specific tricks for speed in addition to the stupid
simple naive memcpy and then let the developer select which one he wanted to
use. That or add a trick to memcpy that checks to see if they do overlap and
delegate to memmove if they do.

~~~
madhouse
Such a runtime check would be too costy, I believe.

I do agree, though, that it's not glibc's problem, however, I also agree with
Linus (and other commenters) who believe that knowingly shipping a Fedora
release with broken flash is stupid, especially when the problem and the fix
is already known, and is fairly trivial.

(Those programs that desperately need the faster memcpy, if it is faster to
begin with, can LD_PRELOAD it)

