Re: find (and friends) bug?

[Tom Lord]

   Tom Lord <address@hidden> writes:

   > Or just presumed that Emacs would use it's own code and that other
   > programs probably don't care about the performance of that function.
   > I'd bet that's a safe bet.

   No, it should be implemented right--even better.

   > Still, it'd be better to leave that function out and force link errors
   > rather than provide a version that silently thwarts reasonable
   > performance expectations.  And anyway, having lots of non-standard
   > names exported from the libc on a platform where lots of relatively
   > inexperienced programmers are working, while very GNUish, is not my
   > favorite feature of glibc.

   Oh, who really cares; 

You do because you want the library to be "implemented right".
Consider the case at hand:

To be a standard C library, glibc has to export the Posix regexp
functions.  Historically, it went beyond that and provided the GNU
regexp functions -- that created a maintenance burden.

Then, for whatever reason, the implementation of the Posix regexp
functions changed, but there apparently wasn't time enough to fix one
of the GNU regexp functions the right way.  Taking a more conservative
approach to what is exported from glibc in the first place would have
prevented this particular problem.  It would have lowered the cost of
changing the regexp implementation in glibc, making it more practical
to do it right.

-t