Re: Upcoming GLib changes
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Subject: Re: Upcoming GLib changes
- Date: 01 Jul 1999 10:46:06 -0400
Trog <email@example.com> writes:
> On 30-Jun-99 Tim Janik wrote:
> > On Wed, 30 Jun 1999, Trog wrote:
> >> > GString
> I don't disagree with anything you've said, given the position you
> are saying it from. I do, however, disagree with your position. It is
> desirable to use strings as a mechanism for reducing (or eliminating)
> buffer overflow problems. That is why most people do a strings
> implementation. GLib does not provide that - and your position is
> that it shouldn't aim to. This, unfortunately, also makes the strings
> implemenation virtually worthless, as I don't think that anyone will
> use it as a consequence of that position.
The current GString implementation is meant to be used where buffer
overflows are a problem - when one is taking bits of strings, adding
characters, etc. When you are just passing around strings, overflow
is not a problem, so one might as well pass a char *.
There are a few missing functions that we need to add to make GString
really useful - the one I tend to miss is:
g_string_insert_n (GString *string, gchar *new, gint n);
But I don't think we need to wrap every single thing that you can do
with a char * with a GString. The conversions are easy enough.
Conversion from GString => gchar *
Conversion from gchar * => GString
> Even gtk+ hardly uses the current implementation.
It's not like GTK+ is very heavy on string manipulation.
A lot (though not all) of the places that could
benefit from GString do use it.
] [Thread Prev