[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
- [PATCH 1/2] Fix memory allocation in the common library., Christopher Brannon, 2010/10/02
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Christopher Brannon, 2010/10/02
- [PATCH 2/2] Use GLib allocation in the audio subsystem.,
Boris Dusek <=
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Christopher Brannon, 2010/10/02
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Boris Dusek, 2010/10/03
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Andrei Kholodnyi, 2010/10/04
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Hynek Hanke, 2010/10/05
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Halim Sahin, 2010/10/05
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Rui Batista, 2010/10/05
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Christopher Brannon, 2010/10/05
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Bohdan R . Rau, 2010/10/05
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Halim Sahin, 2010/10/05
- [PATCH 2/2] Use GLib allocation in the audio subsystem., Boris Dusek, 2010/10/05