Re: g_error_free() warning on null pointer

[Paul <pmcnary cameron net>]

Recently I was re-educated by the Java people that using a null on free
is how they regularly force various Java handling routines they rely on 
SEGFAULT.




On 8/15/2015 4:54 PM, Michael McConville wrote:
> 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