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

[Nicola Fontana <ntd entidi it>]

Il giorno Fri, 17 Jun 2011 14:13:32 +0100
Chris Vine <chris cvine freeserve co uk> ha scritto:

> On Fri, 17 Jun 2011 10:43:24 +0200
> Tadej Borovšak <tadeboro gmail com> wrote:
> > 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).

If you have to free a const pointer you need to explicitely cast it to
non-const to avoid a warning (in gcc at least). This seems to me a clear
indicator the returned value should not be freed.

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

I had this same issue on my own project: you cannot use const on any
referenced type because this prevents you from further
referencing/dereferencing the returned instance. I suppose GTK+
has the same problem and does not use const more because of a
lack of syntactic sugar.

Ciao.
-- 
Nicola