Glibc change exposing bugs [LWN.net]

Glibc change exposing bugs

Posted Nov 11, 2010 0:00 UTC (Thu) by nix (subscriber, #2304)
In reply to: Glibc change exposing bugs by jwb
Parent article: Glibc change exposing bugs

Note that glibc broke the JVM back in glibc 2.3.x days, when it made its internal symbols private and suddenly the JVM was discovered to have been relying on internal libc symbols. That made it not *start* at all, and at that point it was very closed-source, so nobody could fix it. Inevitably there were calls to revert that change and make all the glibc symbols public again. Sensibly, the glibc developers didn't do that: instead, the idiots using internal libc symbols fixed their bugs.

The same will happen here.

(Log in to post comments)

Glibc change exposing bugs

Posted Nov 11, 2010 0:08 UTC (Thu) by lmb (subscriber, #39048) [Link]

A start-up failure is acceptable. A straight crash might be OK, if it is unavoidable (even though then I'd already worry). Data corruption - compared to previous behavior - is not.

Of course it will cause the code to be fixed. But that the maintainers of the core system library place "I am right" above users's data is a worrying insight.

Glibc change exposing bugs

Posted Nov 11, 2010 0:26 UTC (Thu) by bojan (subscriber, #14302) [Link]

> 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.

Glibc change exposing bugs

Posted Nov 11, 2010 10:53 UTC (Thu) by nix (subscriber, #2304) [Link]

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.)