Re: gtk_label_get_text() string duping
- From: Tim Janik <timj gtk org>
- To: Havoc Pennington <hp redhat com>
- Cc: Hacking Gnomes <Gnome-Hackers athena nuclecu unam mx>,Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: gtk_label_get_text() string duping
- Date: Mon, 26 Jun 2000 03:59:36 +0200 (CEST)
On 25 Jun 2000, Havoc Pennington wrote:
>
> Tim Janik <timj@gtk.org> writes:
> > doing *nothing* about this issue is definitely the worst choice,
> > irregardless of what justifications are presented for inaction.
> >
>
> I'm not saying do nothing, I'm saying we have already been acting for
> a long time, over a year, and changing the solution we advocate after
> all that time is going to be major pain. We have already solved the
> problem, maybe it was the wrong solution, but it's too late to change.
>
> i.e. for the last year or so I thought we were solving this problem by
> making all new code return a copy, and there's a _bunch_ of code that
> does that. Maybe not all code, but GConf, Pango, and Bonobo definitely
> return copies from get_*() functions. So the authors of all that code
> thought we had the convention "return a copy." And we've been telling
> people on mailing lists and in docs that that's the convention.
>
> There's a ton of libraries and apps to change in CVS, and you get zero
> assistance from the compiler in doing so.
i didn't propose changing function semantics silently, leaving us with
leaks or crashes all over the place. i'm not *that* short sighted, which
is why i proposed renames.
> Since we have been using this solution for a year, it's pretty hard to
> change now. In fact I bet it's at least several weeks of work, and
> would leave a lot of leftover bugs since broken code will always still
> compile without warnings. It's a bad idea to spend these few weeks on
> something that will confuse everyone, create bugs, break APIs, etc.
> The advantage just isn't large enough.
that's not what i'm proposing, as i couldn't anything but just
agree with you here.
> If we make a change, maybe make "get" mean "make a copy", and come up
> with another name to mean "return a reference". That way all the
> existing "get" code continues to work.
that would be fine, if it really were that way. then we could just
use "peek" or soemthing for non-copying getters. but as it stands,
this really affects only strings, so the convention will be more like:
A:
1) _get_ returns direct values for anything non-string (structures, objects),
you need to do copyies yourself.
2) strings are returned g_strdup()ed, you have to free them yourself.
for some functions there are also "peek" variants in place that return
an uncopied string. beware of old _get_ functions that still return
uncopied strings, you can spot those from the *compat.h files, e.g:
#define gnome_file_entry_get_full_path gnome_file_entry_peek_full_path
while what i'm proposing is:
B:
1) _get_ returns direct values for anything, including strings, you always
need to do g_strdup() etc. yourself
2) some accessors, especially for strings are named _dup_. they do an extra
g_strdup() for you, you have to g_free() their return values.
3) for compatiblity, some functions may still return duplicated strings and
thus leak if you don't free their return values, you can spot those from
*compat.h, e.g.
#define gnome_file_entry_get_full_path gnome_file_entry_dup_full_path
of these two, B: is least disruptive, and A: is a convention even
inconsistent in itself.
since you are arguing a lot in terms of "the gnome hackers", i'm now
Cc:-ing gnome-hackers. that may help getting a better consensus for
either solution.
>
> Havoc
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]