Re: Does g_key_file_free() free pointers from g_key_file_get_string()?

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 17 Jun 2011 10:43:24 +0200
Tadej Borovšak <tadeboro gmail com> wrote:
> > Since the documentation says it's a newly allocated string, I have
> > always freed the string when I no longer need it. This hasn't
> > produced any ill effects so far. Usually, valgrind will catch
> > problems related to freeing pointers to non-heap memory.
> 
> Another indicator that returned value should be freed is lack of const
> modifier on return value.
> 
> If API docs state:
> 
> const char * get_something ()     -> do not free result
>       char * get_another_thing () -> free result

This is certainly not true of the C language: in the C language, naming
a variable as const has no effect on whether its storage may or may not
be freed where it happens to be allocated on the heap, and the same is
true of C++ (the delete expression may happily to applied to pointers to
const, or indeed const pointers to const).

Furthermore, I do not believe it to be a convention adopted by GTK+/glib
either.  Apart from the case of C strings, I believe GTK+ eschews any
use of the const keyword in order to avoid const poisoning.  I am happy
to be proved wrong, but I cannot off the top of my head recall any case,
other than a C string, where an object is returned in GTK+ by pointer
to const.

The only rule to apply is to see if the documentation says whether
ownership is retained by GTK+/glib, or whether an object must be freed
or (in the case of a GObject unrefed).  Sometimes the documentation
states this, and sometimes it doesn't.  Where it doesn't, it is
necessary to look at the source.

Chris