On 10 Jan 2002, Thomas Bushnell, BSG wrote:
> > These are questions that any competent development manager at a software
> > company might ask you when you come to him or her with dreams about
> > gold-plating. And you'd be immediately assigned to some work, seeing
> > that you have lots of time on your hands.
>
> Sure, I'm happy to supply patches to glibc to add the functions. Is
> that all that's necessary here?

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.

How about taking a look at getc() and putc() performance issues
instead? There has been some talk in this list about poor performance
of these (I didn't follow all of it).

> 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.

> I remember when Ulrich spent a lot of effort fixing up all the math
> functions, implementing a dizzying array of them. Most of them are
> very, very, rarely used. But this was very important work (thanks
> Ulrich!) and it was the right thing to do. I guess you think it's a
> waste.

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.

Moreover, these strl*() functions are *not* needed as a building block
for alternate string representations. A dynamic string library has
no need for them; it knows the length of a string, and so if a string
needs to be deeply copied, it can use memcpy(). The memcpy function
does need to run like hell, because it's the standard C idiom for
copying memory, and can be used in some algorithms that can be considered
reasonably intelligent.

The strl*() functions are temporary stopgap measure for some security
problem caused by a limitation in the program, a limitation that ought
to be removed anyway. Temporary stopgap measures don't have to be fast,
they only have to stop crackers so that people don't have to pull the
software off their servers while waiting for a more thorough fix.

On the other hand, it's not hard to imagine some number crunching
program heavily using some math function whose use is not nearly
as easy to reduce or remove.

The function may be very rarely used, in the sense of being used by few
programs. But in that small number of programs, it might be used a lot.

Say, was Knuth wearing the mantle of a foolish, short-term-focused
IT manager, when he wrote that premature optimization is the root of
all evil?

An IT manager who asks smart questions, like whether a developer should
be making code changes to optimize a rarely executed function, and asks
for a case based on profiling data, is hardly a fool. Being a thorn in
your backside doesn't make someone a fool.

> 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.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]