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