This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: safe string copy and concetation
- To: Christoph Hellwig <hch at caldera dot de>
- Subject: Re: PATCH: safe string copy and concetation
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Tue, 8 Aug 2000 12:09:36 -0700 (PDT)
- cc: Ulrich Drepper <drepper at cygnus dot com>, libc-alpha at sources dot redhat dot com
On Tue, 8 Aug 2000, Christoph Hellwig wrote:
> Date: Tue, 8 Aug 2000 20:10:40 +0200
> From: Christoph Hellwig <email@example.com>
> To: Ulrich Drepper <firstname.lastname@example.org>
> Cc: email@example.com
> Subject: Re: PATCH: safe string copy and concetation
> On Tue, Aug 08, 2000 at 09:43:59AM -0700, Ulrich Drepper wrote:
> > Christoph Hellwig <firstname.lastname@example.org> writes:
> > > this patch implements the string functions strlcat and
> > > strlcpy for gnu libc.
> > This is horribly inefficient BSD crap. Using these function only
> > leads to other errors. Correct string handling means that you always
> > know how long your strings are and therefore you can you memcpy
> > (instead of strcpy).
> memcpy for strings is plain ugly. memcpy will not null-terminate
> your strings and led to source-bloat.
It will if you memcpy len + 1 bytes. That's what Ulrich means by knowing
how long your string is.
The purpose of strlcpy and strlcat is simply to protect the system against
> There are some people outhere that like clean and safe solutions
> better than fast ones ...
Except that dropping data to an arbitrary buffer size can hardly be called
safe. There are circumstances in which it is acceptable because it has no
substantial consequences. For example, an error message sent to a log file
may be truncated; the consequence is that the operator may be unable to
decipher the message which is likely a minor issue. But what if strlcpy() does
something nastly, like chop two distinct path names so that they become
I agree that these functions are great for emergency stopgap fixes for security
holes in legacy code. If you have some broken program that uses naked strcpy
and strcat, the easiest way to plug the buffer overflows is with strlcpy and
strlcat, without any consideration for other consequences of the truncation,
which are considered to be of secondary importance to the urgent need to fix