Re: strlcat()/strlcpy(): can it be added to glib now?
- From: Tim Janik <timj gtk org>
- To: David Wheeler <dwheeler ida org>
- Cc: gtk-devel-list gnome org
- Subject: Re: strlcat()/strlcpy(): can it be added to glib now?
- Date: Thu, 17 Aug 2000 23:23:58 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]