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

[Tim Janik <timj gtk org>]

On Wed, 9 Aug 2000, David Wheeler wrote:

> 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?
> 

Wed Jul 26 05:47:48 2000  Tim Janik  <timj@gtk.org>

        * configure.in:
        * testglib.c:
        * gstrfuncs.c:
        * glib.h: added g_strlcat() and g_strlcpy() wrappers, supplied by
        David Wheeler <dwheeler@ida.org>:

        * glib.h, gstrfuncs.c: added g_strlcpy and g_strlcat to support
          safe manipulation of fixed-length string buffers.
          These functions were originally developed by Todd Miller to simplify
          development of security-related programs, and
          are available on many (but not all) Unix-like systems,
          including OpenBSD, FreeBSD, and Solaris.  See
          ftp://ftp.openbsd.org/pub/OpenBSD/src/lib/libc/string/strlcpy.3
          and http://www.openbsd.org/security.html.
          If there's a strlcpy/strlcat on the system, it's called, otherwise
          an implementation is provided.

        * testglib.c: Added tests for g_strlcpy, g_strlcat.


> * There's a minor issue in that there's resistance to including a new header
>   file, which would be needed if the type size_t were used.  So, I've used
>   "gsize" instead, per Tim Janik (see the posts around June 12).
>   Although I think it'd be best to add the new header, I understand why
>   there's resistance, so I'm "going with the flow" & it should be easy to
>   change later if desired.

the real issue is that stddef.h provides size_t only on _some_ systems, and
definitely not ssize_t. so apart from the issue of using g* types anyways,
gsize and gssize will have to be used throughout the glib headers and not
size_t or ssize_t.
i did add appropriate configure.in checks though, so for HEAD gsize has
the correct size now.

> * I include a boatload of tests, and the implementation flies through them.
>   It's essentially the same code as in the BSD's anyway.
> 
> * So - now what?  I don't think there's "malice" or "issues", I just think
>   this little patch got lost in the sea of big changes.

sorry i didn't reply earlier, i think i applied your patch within doing
a bunch of other stuff and simply forgot about notifying you ;)

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

---
ciaoTJ