Re: strlcat()/strlcpy(): can it be added to glib now?

[Ian Main <imain netidea com>]

On Wed, Aug 09, 2000 at 12:44:45PM -0400, Owen Taylor wrote:
> 
> "David Wheeler" <dwheeler@ida.org> writes:
> 
> > On June 14 I submitted a revised patch to add g_strlcat() and g_strlcpy()
> > to glib. I haven't heard any negative reaction to it, but I think it got
> > lost in the sea of other changes.  Can this patch be applied now?
> 
> If people want to see some arguments for why some people consider 
> strlc* harmful, look at the recent thread titled:
> 
>  PATCH: safe string copy and concetation
> 
> At:
> 
>   http://sources.redhat.com/ml/libc-alpha/2000-08/threads.html

While Ulrich Drepper and party have a point, I beleive they are
arguing against its use in areas where it would not be useful.
There are times when strlcpy() would be useful.

The argument about string concatenation and the discarding of data
is fine, but this happens with many functions, including g_snprintf() 
etc. 

(as an aside, g_snprintf doesn't return -1 if the new string was
too long for the buffer, which most snprintf() implementations do.
I can send a patch if you want this fixed.  The only problem being
that we will be depending on the native vsnprintf() working correctly.)

And the argument "OpenSSH programmers are wrong, ProFTPD programmer
is correct" with regards to what is good security practice is umm
interesting :)

> I can't really bring myself to care that much - I tend to avoid
> to avoid fixed size buffers, and I think that is the GLib style.
> 
> (Yes, there is an argument that alloc'ing your buffers arbitrarily
> big allows DOS attacks. But in most cases, that doesn't matter.)
> 
> If people want to add g_strl*, it's not a big concern to me,
> though you won't find me using them.

I would not use them much either, but there are cases where they
can be useful.  As an example, I was revamping the njs javascript
interpreter, and it uses a static buffer in the VM struct to store
errors.  Under normal circumstances, the error string would never
be longer than the buffer it was given, unless it was an attempted
overflow.  In the case of njs, there were holes all over from
improper use of sprintf() and strcat into this buffer.  (The struct
contained function pointers which could have been used to gain
control from an overrun).

You also tend to use fixed length buffers for use with eg, open(3) and
other libc/system functions.

Ian