On Wed, Dec 21, 2005 at 12:00:52AM +0100, Emmanuele Bassi wrote: > Can you please open a bug inside http://bugzilla.gnome.org and attach > the patch there? Tracking patches on Bugzilla makes things easier than > on a mailing list. Shall do. > Apart from g_string_new_lenz() which I don't understand, the _clone() > and _slice() functions looks intersting. Sorry about that one. See other mail... I'd added _lenz() on account of a misunderstanding of how g_string_new_len() works - I thought it didn't guarantee nul-termination, but it does. I'll resubmit another patch, and add to bugzilla, without that function. > > gint g_string_indexof(GString *str, gchar c); > > This would be useful with Unicode support, or with a gunichar variant. Hmm.... A tricky question. In this simple case of looking for a gchar, it's just scanning for a byte. As soon as we bring in Unicode, the question is asked what encoding is it..? I guess we mean UTF-8 here? Is it accepted that all Unicode strings are UTF-8 encoded? I can have a go at a Unicode-aware _indexof(), sure... but currently I just wrap g_strchr() for that case, so I'd need to know how to handle it in UTF-8. <snip> > Also, a > > gchar ** g_string_tokenize (GString *str, > const gchar *token, > gsize lenght); > > Could be interesting, instead of creating a new StringList type, since, > if you want a list of GString, you can always iterate on the returned > strings vector. Hmm.. That one seems a little messy to me. GString in, GString out. Or gchar* in, gchar* out. If it takes in a GString*, but returns a gchar**, that's sort of a mix of types. I don't know how anyone else feels about that, but it doesn't quite feel right to me. -- Paul "LeoNerd" Evans leonerd leonerd org uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Attachment:
signature.asc
Description: Digital signature