RE: PATCH: safe string copy and concetation

["MacGyver" <macgyver at tos dot net>]

> On Tue, Aug 08, 2000 at 09:43:59AM -0700, Ulrich Drepper wrote:
> > Christoph Hellwig <hch@caldera.de> 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.
>
> There are some people outhere that like clean and safe solutions
> better than fast ones ...
>
>
> > Beside, those who are using strcat or variants deserved to be punished.
>
> What's the problem with strlcat.
> strcat is insecure and strncat inconsecuent, but strlcat?
> Have you actually read the patch ...
>

Actually, I agree with Ulrich and company on this.  Safe string handling, if
needed, should be implemented on an application by application basis.  You
can't rely on strlcat() and strlcpy() to exist on all platforms anyway, so
I'd end up implementing them in my package anyhow.  I maintain a reasonably
popular/portable package -- ProFTPD -- and I implement my own safe string
handling functions precisely because:

1) Portability -- I know my version will work everywhere.

2) Peace of Mind -- I use my string functions only in particular cases, and
I know the consequences and side effects
                    of my implementation.

3) Speed -- Because I know my specific requirements in my string functions,
they're optimized to suit my purposes.

My conjecture is that otherwise, people will sloppily implement string
handling in their applications thinking they're safe from an entire class of
problems (namely buffer overruns), when in fact they are only masking the
true problem of bad code to begin with.  For example, snprintf() was
initially hailed to be the end of *printf() style buffer overruns.  Yet
there's still lots of code out there that looks like:

snprintf(buf, sizeof(buf), smashthestack);

instead of

snprintf(buf, sizeof(buf), "%s", smashthestack);

-Mac