strlcat()/strlcpy(): can it be added to glib now?
- From: "David Wheeler" <dwheeler ida org>
- To: gtk-devel-list gnome org
- Subject: strlcat()/strlcpy(): can it be added to glib now?
- Date: Wed, 9 Aug 2000 10:09:34 -0400
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?
Here's a little background:
* g_strlcpy and g_strlcat support safe manipulation of fixed-length
string buffers.
Yes, often dynamically-allocated buffers are easier, but sometimes you
want fixed length buffers (or want to pretend that you're using them).
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' C libraries,
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.
I want this added because I want it to be easy to write code that avoids
security problems; this is a small step to that end.
* I originally proposed this idea on April 24; I've heard no objections.
* On May 2 Tim Janik said that "providing wrappers for standard libc
(BSD and solaris 8 i consider standard enough) functions for portability
reasons is definitely within the scope of GLib."
Sounded good, so I wrote a patch.
* I submitted my "first version" patch on May 5 to this mailing list.
* On June 10 Tim Janik posted a review of the patch, saying:
"your patch seems technically ok, so i've got mostly stylistic comments."
* I resubmitted the patch to this mailing list on June 14, fixing the
stylistic issues noted by Tim Janik.
* 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.
* 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.
--
--- David A. Wheeler
dwheeler@ida.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]