Re: gtk_label_get_text() string duping

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes: 
> i raised that at some point on irc with owen, and had to find
> out that while most of the original gtk API tries to return
> values by reference (and i was following that scheme with
> new functions), he was trying to establish duplication of
> return values for new function implementation.
>

This goes back quite some time too, for example
gtk_editable_get_chars() in GTK 1.2, it isn't new in CVS HEAD. I have
a sense that almost everyone was in agreement here and that the
general convention throughout gtk and gnome was to return a copy.  I
know I have said on gtk-list dozens of times that the convention is to
make a copy, and it's probably in various pieces of documentation.
So if you take a poll of experienced GTK programmers I'd expect most
of them to say "copy".

My sense is that it's too late to change this, but perhaps if we
actually counted up how many _get_ functions copy the returned string
in GTK and GNOME then the answer would be different. Do we have any
sense of how many functions behave in each way?

I know that GConf and Pango always make copies, the new text and tree
widgets always make copies, new stuff in gnome-libs HEAD, etc. It's
just a whole world of work to change this. A _lot_ of
work. Realistically, the work isn't going to get done, and that means
it will be half-finished and we'll have even more inconsistency than
before. (I believe you guys could fix GTK, but there's a lot of user
code out there, and lots of other libraries that supposedly follow the
G* conventions...)

Note that we really can't change existing functions; even for relatively
unreleased stuff like Pango, if you change it there won't be any
compile-time errors, and it will be a nightmare to find all the code
that needs fixing. (Of course if const were used as it should have
been, there would be a compile warning, but... ;-) as it is, changing
this for any existing function creates silent breakage.

So on top of creating inconsistency by failing to change everything,
trying to fix this now would likely result in a bunch of memory
corruption bugs...

Havoc