Glibc change exposing bugs (or how memcpy can bite you back)

by madhouse • 16 years ago

4 2 16 years ago

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• 16 years ago

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)

Glibc change exposing bugs (or how memcpy can bite you back)

Related Stories