Glib proposal: add strlcpy and strlcat to glib

["David Wheeler" <dwheeler ida org>]

[A similar message was previously posted on gtk-list.  Havoc Pennington
noted that this discussion really needs to go to gtk-devel-list, so
I'm re-posting the message here with some more details].

Greetings.  I proposing adding the "strlcpy" and "strlcat" functions to
the glib "String Utility Functions" as functions "g_strlcpy" and "g_strlcat".

These functions support using fixed-length string buffers in a
safer & easier manner than strncpy/strncat.  They copy & concatenate
strings, like strncpy/strncat, but with the following differences:
(1) they _ALWAYS_ NUL-terminate if the destination has length.
(2) they take the full size of the buffer (not the space left over,
   so you don't have to (mis)calculate what's left on each call).
(3) strlcpy doesn't NUL-fill the remainder of its destination
   (strncpy imposes a significant performance penalty because it _does_).

These functions are a key ingredient
in OpenBSD's thrust to make their OS secure, and many OS's ship with them
(including OpenBSD, NetBSD, FreeBSD, & Solaris 8).  Having these functions
available makes it easier to create secure code and to avoid bugs.
The functions strlcpy/strlcat aren't available everywhere, so putting
them in glib simplifies porting.  Glibc already supports String manipulation
functions, so this is consistent with the functionality glibc already includes.

It's true that glib already has a number
of functions to work with _dynamically_ allocated strings, but sometimes
you want or must work with a fixed-length array, and sometimes you want to
use a dynamically-allocated array as though it were fixed length.
The existing glib functions g_strndup() and g_strconcat()
dynamically allocate a new array, which isn't the same thing.
Function g_snprintf () does work with fixed-length strings and
could be forced into doing this, but it's an excessively big hammer
for making simple copies and concatenations.  Using g_snprintf() to do this
is both slower & less readable, an abominable combination.

A paper about strlcpy/strlcat (and why they're useful) is at:
   http://www.openbsd.com/papers/strlcpy-paper.ps
The man page & code are at:
 ftp://ftp.openbsd.org/pub/OpenBSD/src/lib/libc/string/strlcpy.3
 ftp://ftp.openbsd.org/pub/OpenBSD/src/lib/libc/string/strlcpy.c
For a discussion on fixed-length vs. dynamically allocated buffers, and the
security problems of both, see "http://www.dwheeler.com/secure-programs".

I asked Todd Miller (the author) about this, and he didn't see a problem
in doing this. The implementation they have is under the "new BSD"
license, which should be easy to incorporate into an LGPL library.
More importantly, the _author_ interprets this as a reasonable thing to do.

Havoc Pennington said:
> I guess the real question is whether we want strcpy and strcat in
> addition to the versions that return new memory. If we want those,
> then the NUL-terminating versions are more consistent with standard
> glib behavior.

I would argue "yes" for the first point: fixed-buffer versions would be useful.
I interpret the second sentence as saying that strlcpy/strlcat would be
more consistent with glib, if glib is to include this kind of functionality
(if I'm misinterpreting, my apologies, please explain).

Any strong objections to including strlcpy/strlcat in glib?


-- 

--- David A. Wheeler
    dwheeler@ida.org