Re: freeing GTK+ memory

[Pablo Yanez Trujillo <yanezp informatik uni-freiburg de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> With GTK+ you also have the option of inspecting the source code.

this is an advantage over closed-source libraries, I agree, but it isn't optimal. Implementation may change over time
and how guarantees that this won't change in the next release? You cannot always download the source code for the simple
question "should I free it or not?" when such a fact should stay in the (offline) documentation. Besides you first have
to know how is the general structure of the GTK+/Glib/etc/ libraries. I admit that that is not so difficult to realize
but it takes "a lot" of time if it's your first time.

I agree with Ian that there are some functions that are not properly documented when it comes to the returned memory.

Pablo

- --
Pablo Yánez Trujillo
http://klingsor.informatik.uni-freiburg.de/
My public key: http://klingsor.informatik.uni-freiburg.de/gpg/supertux.asc


Hrvoje Nikšić wrote:
> On Sun, 2008-10-26 at 16:23 -0700, Ian Puleston wrote:
>> The documentation for gtk_radio_button_get_group() says that it
>> returns a GSList*, but is that a list that it allocated for me so I
>> will need to free it, or is it a pointer to an internal GSList that I
>> must not free? A call to g_slist_free() didn't break anything
> 
> Note that the fact that g_slist_free() didn't break anything doesn't
> prove that the code is correct.  In case of a double free, the breakage
> could still occur at an unrelated point later.
> gtk_radio_button_get_group() amounts to:
> 
> GSList*
> gtk_radio_button_get_group (GtkRadioButton *radio_button)
> {
>   g_return_val_if_fail (GTK_IS_RADIO_BUTTON (radio_button), NULL);
> 
>   return radio_button->group;
> }
> 
> which indicates that you don't get a fresh list.
> 
>> so presumably that's the correct thing to do, but "try it and see"
>> like that is not really the ideal way to design an app.
> 
> With GTK+ you also have the option of inspecting the source code.
> Admittedly not the most pleasant option and in some cases equally
> misleading because it leads to confusion between the interface than the
> implementation, but in any case more robust than "try it and see".
> 
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkFpXAACgkQDzf8xo+0xRVsfACgun6sDL4NYJJWypXKY1vTDEzl
RCMAoIqeKaJz6jvqlzejO4EHxP1briId
=lHor
-----END PGP SIGNATURE-----