Web lists-archives.com

Re: g_error_free() warning on null pointer




Hi;

this whole discussion seems to assume that GLib is, somehow, bound to
the C and/or POSIX specs even for API that the C/POSIX specs do not
cover. That is patently false. If we want to discuss improving the G*
platform API, let's do it without using fallacies like appeal to
authority in the form of the POSIX and ISO C working groups.

On 16 August 2015 at 09:25, Sébastien Wilmet <swilmet@xxxxxxxxx> wrote:

> Consistency is important for a library. It's much simpler to remember
> "all free/unref functions accept NULL" instead of "free/g_free accept
> NULL, g_object_unref not, g_clear_object yes, etc etc".

unref() is not a free function, so there goes the "consistency"
argument for it. All the reference counting functions must *not*
accept NULL; if you're unreffing a NULL value then there is reference
counting bug in your code, because it means something is holding a
pointer to an object, nullifying it, and still trying to access it; if
that happens, your code should keep an actual reference. Silently
discarding NULL is going to mask this bug.

But, to be even more specific: whether or not free functions in G* can
handle NULL is undefined behaviour — except for g_free(), which is a
direct wrapper around free(), and as such it has to handle NULL by
virtue of the C spec. In short: do *not* pass NULL to free functions
provided by GLib, unless they are explicitly documented to allow NULL.

There's a general discussion to be had if we should modify all of our
free functions to be NULL-safe; even though I generally code my free
functions to accept NULL, I consider adding a NULL check everywhere
inside the G* platform to be pointless churn. It also can mask bugs
for data stored inside other data structures, as opposed to allocated
inside a function.

As a side note: the g_clear_* family of functions is meant to be used
to nullify a pointer variable after freeing its contents; these
functions are NULL-safe because they have to, since they need to
nullify the variable at the given address.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list