RE: Upcoming GLib changes

[Trog <trog gtk org>]

> 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.

> 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.

> 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. To that end, we have to
provide a full API, not just say 'oh, convert it to a char* and use
the str funtions.'

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


> 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.

-tony


---
E-Mail: trog@gtk.org
In theory, there is no difference between theory and practice.  In practice,
there is.

Go Bezerk! http://www.gtk.org/~trog