Re: g_error_free() warning on null pointer
- Date: Mon, 31 Aug 2015 23:03:40 -0400
- From: Michael McConville <mmcconv1@xxxxxxxxxxxxxxxxxxx>
- Subject: Re: g_error_free() warning on null pointer
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
1) print an annoying warning
2) call g_free(), which is NULL-safe
3) call g_slice_free(), which is NULL-safe
gtk-devel-list mailing list