Re: g_error_free() warning on null pointer

[Simon McVittie <simon mcvittie collabora co uk>]

On 01/09/15 04:03, Michael McConville wrote:
> Simon McVittie wrote:
> > 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
>
> 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.

You can't look at the source code of all future versions of GLib,
because they don't exist yet.

If something is documented to work, works in GLib 2.44, and doesn't work
in GLib 2.45, then that's a regression (a GLib bug) and should be fixed.

If something is not documented to work, and in GLib 2.44 it emits
warnings about how it shouldn't work but your program happens to survive
anyway, whereas in GLib 2.45 your program crashes, then that is not a
GLib bug and is unlikely to be fixed.

It's essentially the same principle as undefined behaviour in compilers:
even if the only compiler you care about is gcc, "this undefined
behaviour happens to produce the result I wanted in gcc-4.9.1" does not
imply anything about how gcc-5 will compile the same source code.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>