This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Wish for 2002 ...
- From: tb at becket dot net (Thomas Bushnell, BSG)
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Cc: Francois Leclerc <leclerc at austin dot sns dot slb dot com>, Security Audit <security-audit at ferret dot lmh dot ox dot ac dot uk>, Andrew Josey <a dot josey at opengroup dot org>, Tiemann <tiemann at redhat dot com>, <libc-alpha at sources dot redhat dot com>, Robust Open Source <open-source at csl dot sri dot com>
- Date: 10 Jan 2002 20:11:07 -0800
- Subject: Re: Wish for 2002 ...
- References: <Pine.LNX.4.33.0201101914240.31242-100000@ashi.FootPrints.net>
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?