RE: Upcoming GLib changes

[Tim Janik <timj gtk org>]

On Wed, 30 Jun 1999, Trog wrote:

> 
> > GString
> > -------
> > 
> > the newly introduced g_string-*() macros are all broken with
> > regards to
> > GString *string pointer checking and apart from that, accessor
> > macros
> > for the GString structure are unjustified since the valuable bits
> > of
> > the GString structure (gchar *str; gint len;) are exposed through
> > the API
> > and are guarranteed to stay that way through future versions of
> > GLib.
> 
> I asked about the macros at the time and no one commented. Whilst
> what you say is true, these are more for convenience than
> functionality you can't get elsewhere.

sorry trog, i don't even get the convenience point in
g_string_str (foo)
vs.
foor->str
and returning NULL as a string value for a (GString*)0 is simply wrong.
worse than that is g_string_char() since it suggests it'd do bounds
checking whilst it doesn't.
on a more general matter, GLib structures are auxillary structures and
no objects, that's why we don't have g_list_get_prev(), g_slist_get_data (),
et ceteri, and why we don't want them for GString as well.

> > the g_string_ macros are mostly broken.
> > also there is no point in providing wrapper macros for all kinds of
> > string manipulation functions (like g_string_cmp(),
> > g_string_dup()),
> > people can just pass gstring->str to their string manipulatin
> > functions
> > directly.
> 
> In regard to the GString *string pointer checking, you'll find that
> it is no different in the libc str*() functions - they don't check
> values either, so you've neither gained nor lost - there is a return
> value problem with checking them.

if you've been through some GLib (or Gtk) code, you'll notice that it
behaves pretty noisy upon failing assumptions. we simply don't buy into
work-or-die for these projects, eventhough that route may be different
from libc implementations.
uhm, and i don't understand what you mean with "there is a return
value problem with checking them".

> > the g_string_tokenise() and g_string_tokenise_free() functions are
> > also superfluous.  If present at all, they should operate on normal
> > strings, not on GStrings. But that's simply what g_strsplit()
> > already provides.
> 
> Strongly disagree with you here. Very strongly. This is either a
> strings implementation or it isn't. Your argument could be extented
> such that we just through strings away completely. The philosophy
> of strings is that they are 'guaranteed' to provide a data type which
> the user (or anyone else) can't overflow.

we don't provide a GString type as something that is armour plated for
all kinds of usage.
while functions like g_string_append_c() certainly should not cause buffer
overflows, they are meant to *automatically* handle buffer reallocations,
not to make the programmer forget about what language he's programming in.

the point here is, we do not intend to provide a full fledged replacement
for C's char* type, we'd end up wrapping virtually any string manipulation
fucntions in existance. the goal with GString is to have an easily usable
wrapper structure for common string operations that are error prone and
tedious to reimlpement over and over again.

> To that end, we have to
> provide a full API, not just say 'oh, convert it to a char* and use
> the str funtions.'

nope, we do *not* want to wrap all string manipulation functions you
may encounter, especially not those that just take a char* as argument
and return something completely new (non-GString related), e.g. a
GList of char* or a char** array.

> I actually use strings in my programs, and these are the functions
> that I have found that I need to have.

you simply get this behaviour with g_strsplit (gstring->str,...).

> > code like the one found in g_string_readline() and
> > g_string_readline_buffered()
> > should probably apear in the g_io_channel API if there is public
> > demand for
> > such functions.
> 
> See above. If there is a string wrapper, then fine. I haven't used
> g_io_channel (mainly because I haven't seen any documentation for it,
> and don't know what it does).
> 
> The objective is to be able to write a program that just uses
> g_strings everywhere, no char*. It is then very easy much easier to
> check a program for correctness with respect to buffer overflows. It
> just is.

as i said above, the objective is *not* to get rid of char*.

> 
> -tony
> 

---
ciaoTJ