[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: glibc segfault on "special" long double values is _ok_!?

From: Jeremy Linton
Subject: Re: glibc segfault on "special" long double values is _ok_!?
Date: Fri, 08 Jun 2007 14:33:57 -0500
User-agent: Thunderbird (Windows/20070509)

Petr Baudis wrote:
On Thu, Jun 07, 2007 at 05:02:53PM CEST, Jeremy Linton wrote:
From monitoring this mailing list for a while it appears apparent that certain people pride themselves in rejecting any patch which improves the robustness of glibc.

I would describe it rather as not trading performance for hiding
application bugs.
I would describe it as, "fast but brittle". I've been monitoring this list long enough to see patches rejected because they slow a path down by a dozen cycles or so. That kind of change isn't even measurable in any real application. I find this especially silly when there are other things in the same path that are implemented so poorly that a few changes could significantly improve the overall performance. There are places where a rewrites could change a problem from O(N) to O(log N).

While performance matters, correctness is _ALWAYS_ a more important metric. Even if the correctness is simply resistance to errors. The user doesn't care why the application crashes only that it does. I have a kernel space background and it doesn't matter what an application did wrong, its a kernel bug if the kernel crashes. That same statement should really apply to things like libc. I understand that its harder in libc because the fundamental architecture of the API's can make it difficult if not impossible to achieve.

The difficulty in recovering from client errors isn't an excuse for throwing up your hands and rejecting patches. I'm amazed that it gets any traction on this list. Its such a contradictory problem, A robust glibc would help the maintainers as much as the users.

Maybe what glibc needs is a #define ROBUST than can be wrapped around all these "performance killing" pieces of code that simply validate some piece of input or fix some misbehavior in the library that is undefined in the standards. Then distributions (or maybe programmers) can decide whether to use a version that has extra error checking or the version that is a couple percent faster.

More on topic, I would be surprised to find anyone that expects printf and friends to be fast. Someone who really cares about the performance will use other methods for formatting their strings.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]