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


Paul Eggert <eggert@twinsun.com> writes:

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

I think it is very clear to me that the best fix for a strcat/strcpy
bug is to do it right, dammit, and not to cheat with strlcat/strlcpy.
Like I tried to make clear, I think strlcat/strlcpy are bogus, and
nobody should be using them.

But we aren't talking about whether people should be using them
anymore; we're talking about whether libc should provide them for the
sake of other people who want to use them.  If you think the answer is
"obviously not" then why do we have gets and getwd?

And yet, people are.  And I don't think the job of glibc is to tell
people not to use them.  Though, I think a link-time warning is
certainly appropriate.

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

One of them was once, at least, to implement the functions in use on
BSD and SysV systems.  Certainly that is more useful than implementing
the latest random edict from XOpen and Posix.  


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