Re: Glib proposal: add strlcpy and strlcat to glib

On May 2,  7:16pm, Tim Janik wrote:

>>>> Any strong objections to including strlcpy/strlcat in glib?
>>>providing wrappers for standard libc (BSD and solaris 8 i consider standard
>>>enough) functions for portability reasons is definitely within the scope of
>>>GLib. i'm very likely to apply a patch with reasonable implementation held
>>>in usual GLib style to CVS HEAD.

Okay, great!  I'll whip up a patch soon, using gtk+ style.

A few quick notes:
* The original functions use "size_t" for buffer size & return values.
  I think that's the right type to use, but does someone strongly prefer
  using gtk+-ish types (e.g., guint) instead?  I'd prefer to use size_t,
  since if this is a wrapper I'd hate to have to use "incompatible"
  types requiring integeer types translation for no good reason.
* I'll start by just pasting in the implementation; later we can work out
  how to detect these routines & call them where they already exist.
* Technically I can apply this patch myself (I have GNOME CVS access), but
  I've never patched glib before.  From your remarks I assume I should post
  the patch to the gtk-devel list and send it to the "incoming" directory.
  Please let me know if you'd rather that I patched glib directly
  (its CVS HEAD, not 1.2), I want to "do the right thing".
* Naturally I'll write test code (presumably it goes into testglib.c)
  and a ChangeLog entry, as well as even (horrors!) documentation.


--- David A. Wheeler

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]