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.
