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

[Andrei Kholodnyi]

>> Boris Dusek <dusek at brailcom.org> writes:
>>
>> That makes sense.
>> The main reason I settled on GLib is that we're already using it in much
>> of the code. ?Several of the modules link against it for GHashTable,
>> GList, and the like, as does the server.
>> We use GString pretty frequently for accumulating text.
>> To see an example of this pattern, have a look at the do_list_voices
>> function, from module_utils.c.
>> If we prefer malloc and free, we should probably implement
>> something similar to GString. ?Also, we'll want a printf-style function
>> which writes to a dynamically allocated string. ?See g_strdup_printf.
>> It is used extensively. ?asprintf would seem to fit the bill, but it
>> isn't portable. ?I'd vote for borrowing somebody else's implementation.
>> GLib is mostly for convenience, in these cases.
>
> Thanks for the summary. As for printf-like functions, snprintf, which is
> portable, should work (by calling it for the first time to learn the size
> to allocate, then second time to actually do the printing job). The only
> non-trivial thing seems the hash table.
>
> I will look at the things where we use GLib and try implementing
> the small(er) things.

I have a question.
Do you plan to remove GLib, if yes, then why.
The reason I'm asking it was planned to switch to gmainloop,
now, if it is still the case, why do you need to replace glib calls.

Andrei.