Re: gtk_label_get_text() string duping

[Tim Janik <timj gtk org>]

On 25 Jun 2000, Havoc Pennington wrote:

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

right, i outlined that already.

> 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'm afraid not. if you say that's consistent throughout gnome-libs,
then that's at least a hint.

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

i think your overreacting here. for the most part, the changes are
mechanical, you really just need to figure whether a function returns
a copy or not and then rename it/put it into gtkcompat.h.
and if you as a programmer can't spend the time to evaluate this, what
do you expect the user code will look like?

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

while we now accept tons of leaks instead?

rather than whining "we can't change it, there's so much code already",
inadvertantly of the problems casued by the current inconsistencies,
i'd apprechiate comments like:
"i did some survey and figured X _get_ functions in gtk return
 references and Y _get_ functions return copies. also Z _get_
 functions in non-gtk code return copies, with Y and Z each being
 magnitudes of X."
based on that, we could figure that the best course of action could
e.g. be to rename the existing reference returning _get_ gtk functions
to _peek_ and just add those to gtkcompat.h.

doing *nothing* about this issue is definitely the worst choice,
irregardless of what justifications are presented for inaction.

> 
> Havoc
> 

---
ciaoTJ