Re: string return result conventions

["Luke Kenneth Casson Leighton" <lkcl lkcl net>]

tim, thank you for responding.

>> therefore it's important for me to find out what glib / gobject memory
>> conventions are, for strings.
>
> Strings querried through the property interfacem e.g.:
>
> gchar *string = NULL;
> g_object_get (label, "label", &string, NULL);
>
> is always duplicated and needs to be a freed by the caller,
> because the returned string might have been dynmically
> constructed in the objects proeprty getter (i.e. not
> correspond to memroy actually allocted for object member storage).

 ok - in this situation, fortunately we have control over that.  the
property getter is entirely auto-generated.  the code review of the
new webkit glib/gobject bindings brought to light the webkit
convention of not imposing any "memory freeing" of e.g. strings on
users of the library.  use of refcounting is done on c++ objects, for
example.

the strings in webkit are unicode (libicu).  _at the moment_ i'm
alloc-sprintf'ing strings - all of them - into utf-8 return results.

it was recommended to me that i create a string pool system, to keep a
record of strings created, and, at convenient times, destroy them all
(reminds me of apache pools and samba talloc).  exactly when is
"convenient" is yet to be determined, which is the bit i'm not too
keen on :)

looking at the auto-generated code in pywebkitgtk, i'm seeing use of
PyString_FromString which copies arguments passed to it - there are a
number of functions which return strings (not property-getters) - so
there's definitely memory leaks (hurrah).

clearly, the best overall thing would be to actually return the
unicode strings themselves rather than convert them (needlessly?) to
utf-8.

if that's not possible to do, what would you recommend, in this situation?

many thanks,

l.