On 11/26/25 07:12, Markus Armbruster wrote:
Peter Xu <[email protected]> writes:
On Tue, Nov 25, 2025 at 07:48:44PM +0100, Markus Armbruster wrote:
My main argument remains this one: our deallocating functions don't work
that way. For better or worse.
I don't want the Error API free differently.
Yes, it's fair.
IMHO, it's a matter of taste,
Depends on context.
Modula-2's DISPOSE takes the pointer by reference and clears it. C's
free() takes it by value. Matter of taste when these were designed.
But when one style has become overwhelmingly prevalent, it's no longer a
matter of taste. This is arguably the case in C.
and maybe that's also why I liked
g_clear_pointer() but not everyone likes it.. said that, when we have
g_clear_pointer() it also makes the current form more flexible, because we
can apply g_clear_pointer() on top when we need a reset..
I'm no friend of g_clear_pointer(). I find
g_clear_pointer(&ptr, free_frob);
a rather roundabout way to say
free_frob(ptr);
ptr = NULL;
Any C programmer will immediately understand the latter. For the
former, you need to know one more little thing. Yes, we can all get
used to these little things, but it's one more little thing new people
have to learn and internalize. Even little things add up.
If an entire project gets into the habit of using it religiously, it may
reduce "forgot to zap the reference" bugs some. Until then, it feels
like a net negative to me.
I'm not a big fan of g_clear_pointer() either; I prefer being explicit,
even if it means a bit of redundancy.
Thanks,
C.
I'll follow your advise on error reporting for migration.
Thank you!
