Re: g_error_free() warning on null pointer

[Michael McConville <mmcconv1 sccs swarthmore edu>]

Simon McVittie wrote:
> On 16/08/15 20:23, Michael McConville wrote:
> > Emmanuele Bassi wrote:
> > > You expected the *_free() functions in GLib to be NULL-safe. They
> > > aren't, except for g_free().
> >
> > g_error_free is. Maybe others too, I haven't checked. It just prints
> > annoying console warnings.
>
> The intention throughout the GLib-based stack is that if a
> g_return[_val]_if_fail() is hit, it indicates that the caller has
> called the function incorrectly, in a way that is considered to be
> undefined behaviour
> <https://en.wikipedia.org/wiki/Undefined_behavior>. Undefined
> behaviour does not mean "your code will crash"; it means "any result
> is valid, and it is up to the compiler or library author what
> happens". It does in practice end up meaning "your code is wrong",
> because the majority of the possible implementations of undefined
> behaviour are not what you wanted.

I still don't understand how this is relevant. I already understand what
undefined behavior is and how it relates to compilers/optimization.
However, this sort of smoke and mirrors inexactness doesn't apply to
GLib - there's a single implementation and we can just go and look at
the source code and see what it does. In the case of g_error_free, this
is:

 1) print an annoying warning
 2) call g_free(), which is NULL-safe
 3) call g_slice_free(), which is NULL-safe