Re: g_error_free() warning on null pointer

Emmanuele Bassi wrote:
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.

Seems like you didn't read all of it then. This came up at least twice:

Michael McConville wrote:
I wasn't suggesting that it's officially specified. I just think
that this aspect of free() is intentional and useful, and that people
have a reasonable expectation that g_error_free() will conform.

Sébastien Wilmet <swilmet gnome org> 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".


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.

That's what we're trying to change.  ;)  I don't think 'undefined' is a
good term for it, though. It's not some kind of mystery or
non-deterministic optimization outcome. The source code's there, so we
can read it. And there's only one kind of NULL, so we can just test it
too. And there's only one GLib.

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.

I don't follow. Can you share an example? On the other hand, as I
mentioned, forcing NULL checks often leads to memory leaks because
people get unduly conservative about when they free.

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.

I don't understand what you mean here either.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]