speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 2/2] Use GLib allocation in the audio subsystem.


From: Boris Dusek
Subject: [PATCH 2/2] Use GLib allocation in the audio subsystem.
Date: Sat, 2 Oct 2010 22:48:17 +0200

On Oct 2, 2010, at 5:03 PM, Christopher Brannon wrote:

> Now, all memory management in the audio subsystem is done with
> g_malloc, g_free, g_strdup, etc.

Maybe it's too late to question this, but I don't see the point of using
g_(malloc,free,realloc,strdup) instead of using the standard C allocation
functions. The only rule one has to follow is that a resource acquired using
one function has to be released using the release function corresponding to the
acquiring function. E.g. malloc with free, g_malloc with g_free, fopen with
fclose, open with close, new with delete, etc. That is a rule that does not
have anything to do with GLib. And I did not find a rule in the GLib
documentation that would say that one has to allocate *all* memory with the
GLib functions, or that it is preferable.

I read what g_malloc does more than malloc:

1. `g_malloc() always returns a gpointer, never a char*, so there's no need to 
cast the return value.'
malloc returns void *, and gpointer is void *. I don't see what they are 
talking about.

2. `g_malloc() aborts the program if the underlying malloc() fails, so you 
don't have to check for a NULL return value.'
malloc returning NULL is error like any other, so you either recover from it
(by shutting down gracefully), or abort, but in the second case, to create a
dependency on GLib because of just one tiny function is too much in my opinion.
Better have spd_malloc in libcommon to do that.

3. `g_malloc() gracefully handles a size of 0, by returning NULL.'
I would guess that there is some logic inconsistency in the program if you
pass 0 to malloc. So the problem is somewhere else.

4. `g_free() will ignore any NULL pointers you pass to it'
free does ignore NULL pointer as well

To summarize, my opinion is that this creates a dependency on GLib (which is a
big one) without much gain. Tiny things should better be implemented in
libcommon (like spd_getline). Only for the big things should we really use
GLib (e.g. like GSettings, if we want to use them in the future). I am
happy to help with these (e.g. aborting spd_malloc).

Could you (and possibly others) please elaborate on the GLib memory allocation
conversion?

Thanks and best regards,
Boris


reply via email to

[Prev in Thread] Current Thread [Next in Thread]