Re: gtk_label_get_text() string duping

[Tim Janik <timj gtk org>]

On 25 Jun 2000, Havoc Pennington wrote:

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

i can't really proove this. glancing at gnome-libs, the copying enforcement
seems to be as random as in gtk (notably, it's mostly code from you or owen
that bothers doing an extra copy).

definitely most of the non-string returning functions don't copy or add
reference counts. i wouldn't know why they should even, since you can
always copy()/ref() objects on your own, while the string returning ones
seem to be about half half (maybe the copying ones having a bit of a majorty).

i'd btw apprechiate if you enlightened me on why string getters should do
an extra copy at all. i'd guess that code like:
  my_data_model_set_string (g_some_widget_get_string (widget));
is far more common than:
  gchar *string = g_some_widget_get_string (widget);
  chrunch_and_chop_the_copy (string);
  my_data_model_set_string (string);
  g_free (string);
but maybe that's just me.

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

you didn't read my previous post very thoroughly then. if you have
a module that does copying consistently all over the place, it's
half an hour (actually less) of doing grep "char.*_get_" *.h
and stuffing those functions into:

$ cat >rewrite.pl
#!/usr/bin/perl -w -pi.bak

s/gnome_dock_item_get_name/gnome_dock_item_dup_name/g;
s/gnome_file_entry_get_full_path/gnome_file_entry_dup_full_path/g;

then running rewrite.pl over your code.

for established APIs, you just need an additional:

#define gnome_dock_item_get_name gnome_dock_item_dup_name

in your compat file.

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

i highly doubt that. seeing that half of the functions currently
don't provide a copy, and still most apps don't crash after the first
five minutes, this can only be due to two things:

1) all programmers do intensive research to figure whether they
   need to free stuff
2) programmers don't expect to having to free() string getters, as they
   don't have to free/unref other return type getters as well

it should be obvious which of 1) or 2) is more likely.

> 
> Havoc
> 

---
ciaoTJ