Glibc change exposing bugs

> Data corruption - compared to previous behavior - is not.

Now you're making glibc maintainers responsible for other people's bugs. They are not.

If this same buggy program was linked against some other library that implements memcpy() similarly to the way latest glibc does, the data would be just as corrupt.

In essence, it is the program that is corrupting the data, not glibc. And it's doing so by clear misuse of a function.

> But that the maintainers of the core system library place "I am right" above users's data is a worrying insight.

I think that's a bit overly dramatic. Fedora 14 is a fresh release, currently carrying a non-released version of glibc. As such, users of it (which includes me) sometimes encounter things that are surprising at first. But the audience is limited and the impact is not earth shattering.

The glibc maintainers are much harsher than that. Any change which is implementation-defined in POSIX or ISO C's library functions is fair game for them to change, and they have very harsh words for people who complain (and explicitly don't care about breaking closed-source code that depends on such assumptions). Expecting them to insert slowing-down hacks for actively *undefined* stuff, given their somewhat cavalier attitude to implementation-defined stuff, is peculiar. (Their attitude to stuff that *is* defined is appropriately rigid: thou shalt not break it.)