Re: g_error_free() warning on null pointer

[Sébastien Wilmet <swilmet gnome org>]

On Sun, Aug 16, 2015 at 11:53:16AM +0200, Nicolas George wrote:
> Consistency is good, but it is not the only aspect of convenience. Catching
> common bugs is another aspect, pulling in the other direction.
>
> When freeing something, there is always the question "If I am freeing NULL
> here, is it a bug in my program?". If the answer is more frequently "no"
> then the free function should accept NULL silently; if the answer is more
> frequently "yes", then the free function should complain about NULL. The
> answer is not the same for all free functions.

So if you design a library like that, your users will need to read the
documentation everytime they use as simple functions as free/unref.

Consistency is important for a programming language or for a library to
save time to the programmer (and not turning crazy).

To take another example, I always use bitfields to add booleans in a
struct. So, instead of:

struct
{
        gboolean blah;
};

I always write:

struct
{
        guint blah : 1;
};

A bitfield of 1 bit can only be used for a boolean, so the code is
almost as clear as using the more precise type.

Since gboolean is a typedef to a gint, for heavily-used structs it's
better to pack booleans at the end of the struct with bitfields, to
save some memory. For less-heavily used structs (the extreme case being
a singleton), other people prefer to use gboolean because it's slightly
clearer, and fields can be grouped more logically instead of being
forced to put booleans at the end. But in that case, you always need to
think "is my struct heavily used or not?". The answer may be different
over time, after adding a new feature for example. And what does
"heavily-used" mean exactly? It also depends on how many booleans you
have in the struct.

It's far simpler and quicker to always apply the same convention.

--
Sébastien