Re: Wish for 2002 ...

[Paul Eggert <eggert at twinsun dot com>]

> From: tb@becket.net (Thomas Bushnell, BSG)
> Date: 10 Jan 2002 16:43:19 -0800

> Linus claimed to have something approaching "hard data" for the
> proposition that adding functions to the library is inherently bad,

That is different and (to my mind, in this context) less important
than the data that Leclerc requested.  He was asking for the "unit
cost of their remediation for strcat (b , a);", which I interpreted to
be a request for the human maintenance cost for traditional fixes for
strcat/strcpy bugs, as opposed to fixes using strlcat/strlcpy.

This human cost is the most important cost, all things considered: it
dwarfs the CPU costs involved.  (I know that I'm mixing units here,
but in the end all these costs boil down to human costs.)

Software maintenance cost is an area where hard data are extremely
rare.  Handwaving is far more common -- and it's all that has been
cited so far in this thread.  Personally, I'm skeptical that
strlcpy/strlcat has significantly lower overall maintenance cost than
the more standard fixes.  My (admittedly informal) experience is quite
the opposite.  I'm willing to look at any hard data that
strlcpy/strlcat proponents have, but I suspect they don't have any
more hard data than I do.


> those programs are currently not portable.  (Or, if they use an
> autoconfy test,

As they all do -- or at least, all the programs mentioned so far.


> they get a suboptimal implementation of a string function; one of
> the very thing that glibc exists to prevent.)

glibc exists for many reasons.  "Optimality" is one of them, but it is
not the only one.  It is not even the most important one.  We should
not let the tail wag the dog.