Re: gtk_label_get_text() string duping
- From: Tim Janik <timj gtk org>
- To: Havoc Pennington <hp redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: gtk_label_get_text() string duping
- Date: Mon, 26 Jun 2000 03:44:34 +0200 (CEST)
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);
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
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.
] [Thread Prev