This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Wish for 2002 ...


Kaz Kylheku <kaz@ashi.footprints.net> writes:

> You miss the point; that manager will not authorize you to do that
> work. It's not a question of the effort at all, but of ``managing
> away'' unnecessary development and thus any of its associated risks.

But so what!  It's *my* time to spend, and I hereby volunteer to spend
it that way.

> > Do you think that efficient string functions are unimportant?
> 
> I think that optimizations of nonportable string functions are
> unimportant. And I think that premature optimizations of functions
> with uncertanties in their semantics are foolhardy.

Except (and this is the joy of the thing), we have already optimized
them.  All we need to do is write the new interfaces for the already
existing glibc string function optimizations.

> However, string copying is not a math function. Any program that
> spends a significant proportion of its execution time copying strings
> can likely be optimized by doing something a smarter than making
> strlcpy run like hell. 

Um, you missed my point, didn't you?

Why does libc have bcopy, memcpy, strncpy, and all the rest?  (Do you
need a hint?)

But the point is:

1) These functions exist in BSD libc, which used to be a sufficient
   argument all by itself for why they should in glibc.
2) These functions are in growing use by many programs.
3) Implementing these functions in one place is better than
   implementing them in each of those many programs.

> > Perhaps this is
> > reasonable in business, but this is not a business.
> 
> If this is not a business, then it can wait a few seconds for OpenSSH
> to complete a strlcpy operation.

So, to summarize:

1) We should not add these functions because it will make glibc a tiny
   bit slower. (Linus)
2) We should not add these functions because we don't really care
   about tiny improvements in speed. (Kaz)

Can you pick a single story and keep it straight?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]