Re: string return result conventions

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

>> 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 :)
>
> We've done a simialr thing in beast (beast.gtk.org), where we pile up
> strings in a garbage collector pool and free them, once the topmost
> main loop level is reached. This works fairly well in practice, it
> however does have the following downsides:


tim, thank you for that - i did some tracking and found that
python-gobject looks like it uses PyString_AsString, meaning that it
"takes over" ownership of the memory containing the string passed to
it (as opposed to PyString_FromString which takes a copy).  so, it
would appear that entirely by accident i've done the right thing by
using g_strdup (of the c++ unicode strings converted to utf-8)

awww, i'm disappointed: i was expecting to have to clear up huuge
memory leaks :)

regarding the strings that i was returning as const gchar* - my take
on this is that i was doing slightly the wrong thing, and should have
been returning gchar*.  that's my story, and i'm sticking to it.
end-result: strings returned must be "owned" by the caller, and that's
easily taken care of by adding   (caller-owns-return #t) in the
webkit.defs (in pywebkitgtk) - and ... the potential problems, along
with the rather awkward solutions, are avoided.

let's see if it passes review / patch acceptance :)

thank you people.

l.