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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
