Glib proposal: add strlcpy and strlcat to glib

["David Wheeler" <dwheeler ida org>]

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 using strncpy/strncat.  They're a key ingredient
in OpenBSD's thrust to make their OS secure.  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.

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.

On Apr 22, 12:05am, Todd C. Miller wrote:
> Subject: Re: Adding strlcpy and strlcat to "glib"
>>>Sounds good to me.  I don't see any reason why the license would
>>>prevent you from including it.  We tried to get the GNU libc guys
>>>to include strlcpy/strlcat but they weren't interested.  I'm aware
>>>of the following OSs that ship with strlcpy/strlcat:
>>>    OpenBSD
>>>    NetBSD
>>>    FreeBSD
>>>    Solaris 8
>>>
>>> - todd
>>>
>>>In message <200004220530.BAA18088@aphrodite.csed.ida.org>
>>>	so spake  (dwheeler):
>>>
>>>>  Hello!  I'm interesting in adding strlcpy and strlcat to the "glib"
>>>> library. Glib is a basic portability library that's the basis of
>>>> the X GUI tookkit GTK+ (and thus GNOME and the GIMP, for example).
>>>>
>>>>  As far as I can tell, your license permits this anyway, but I'd like
>>>> to hear your thoughts first before doing so.
>>>>
>>>>  My rationale for adding strlcpy/strlcat to glibc
>>>> would be to simplify implementing portable applications that are still
>>>> secure.  Having a simple library to ensure that there's an
>>>> implementation is likely to increase its use where appropriate.
>>>>
>>>>   I suspect they'd be named something like g_strlcpy and g_strlcat
>>>> (to be consistent with its naming convention), and it's just be an
>>>> alias for strlcpy/strlcat if those are already defined on that platform.
>>>> So, if strlcpy were added to the C standard later, this wouldn't cause
>>>> a problem.
>>>>
>>>>  Thanks.  Looking forward to any comments you have.
>>>>
>>>>
>>>
>-- End of excerpt from Todd C. Miller



-- 

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