Jasper St. Pierre wrote: > Lots of things in GLib fail when passed a NULL pointer, like > g_object_unref.
I'm talking about free()-family functions specifically, though. They have a POSIX-specified behavior that people expect. > The idea is that passing a NULL pointer is probably a sign of a bug > somewhere, so you shouldn't do it. I definitely don't think it's evidence of a bug. This is common practice in POSIX-compliant C. More to follow. > While the C standard's free() is NULL-safe, I'd say that this is quite > strange for the C standard, since any other invalid pointer passed to > free() would (most likely, though yes, implementation-defined) crash. Rather than strange, I'd say it was intentional and insightful. In function bodies, you often have pointers that are used in conditions and may or may not be null. There's a very easy and clean way to deal with this: initialize them to NULL at the beginning and free them at the end. Freeing conditionally in the body can be awkward and often leads to memory leaks. I can send you a few examples from the Pidgin codebase if you're interested. More circumstantially, the entire POSIX description for free() is four sentences. I doubt that allowing null pointers was added as a complicating distraction. It's a core part of a simple interface. I'm not insisting that you code this way. Most simply, I'd say: * many programmers already assume POSIX compliance * g_free() already complies with POSIX on this * people clearly associate g_error_free() et al. with free() and g_free() * these functions might as well behave the same I really can't imagine anyone using these warnings. I can imagine people being distracted or misled by them, though - I was. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
