Re: g_error_free() warning on null pointer

[Michael McConville <mmcconv1 sccs swarthmore edu>]

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.