Re: g_error_free() warning on null pointer
- Date: Sat, 15 Aug 2015 17:54:18 -0400
- From: Michael McConville <mmcconv1@xxxxxxxxxxxxxxxxxxx>
- Subject: Re: g_error_free() warning on null pointer
Jasper St. Pierre wrote:
> Lots of things in GLib fail when passed a NULL pointer, like
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
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
* 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