Before the patch: bugs in generic module

[Bohdan R . Rau]

Hi all

After careful reading generic module source I decided to rewrite it almost
from scratch. I don't expect working version in nearest days, and even I'm
not sure my code will be accepted.

In meantime I found some bugs in generic module...

1) generic module does not show voice list.

Funny. I wrote a small piece of code, but I think there is a bug in other
place: if in AddVoice I use spaces in voice name, LIST SYNTHESIS_VOICES
command works incorrectly.
As I couldn't find any informations regarding spaces in synthesis voice
names, there is a bug for me.
One possible solution is to replace spaces into underscores in AddVoice
callback.
Should I provide patch for it?
Source of my module_list_voices for generic module below - sorry not as
patch, but as it's not complete please treat it only as code to review.

--- cut here ---

SPDVoice**
module_list_voices(void)
{
    extern GHashTable *module_voice_table;
    static SPDVoice **vlist;
    if (vlist) return vlist;
    if (!module_voice_table) return NULL;
    int num=g_hash_table_size(module_voice_table);
    if (!num) return NULL;
    GPtrArray *ga=g_ptr_array_new();
    void adlang(char *key,char **value,gpointer unused)
    {
        int i;
        for (i=0;i<8;i++) if (value[i]) {
            SPDVoice *voice=g_malloc(sizeof(*voice));
            voice->language=g_strdup(key);
            voice->name=g_strdup(value[i]);
            voice->variant=NULL;
            g_ptr_array_add(ga,(gpointer)voice);
        }
    }
    g_hash_table_foreach(module_voice_table,(GHFunc)adlang,NULL);
    g_ptr_array_add(ga,NULL);
    vlist=g_ptr_array_free(ga,FALSE);
    return vlist;
}

--- cut here ---

2) where I don't set output language, it's set to english and iso-8859-1
encoding.

Funny. As generic module will be probably used mostly for non-english
languages, there should be some mechanism which sets default language as
one of supported, not code author native language :)

Of course I could provide GenericDefaultLanguage parameter, but for me
it's not necessary and may cause bugs (when GenericDefaultLanguage is not
on GenericLanguage list). Instead - I slightly rewrote MOD_OPTION_3_HT
macro, so I can use first key as default. Small piece of code:

--- cut here ---

#define MOD_OPTION_3_HT(name, arg1, arg2, arg3) \
    typedef struct{ \
        char* arg1; \
        char* arg2; \
        char *arg3; \
    }T ## name; \
    GHashTable *name; \
    char *HT_def_ ## name; \
    \
    DOTCONF_CB(name ## _cb) \
    { \
        T ## name *new_item; \
        char* new_key; \
        new_item = (T ## name *) g_malloc(sizeof(T ## name)); \
        if (cmd->data.list[0] == NULL) return NULL; \
        new_item->arg1 = g_strdup(cmd->data.list[0]); \
        new_key = g_strdup(cmd->data.list[0]); \
        if (!HT_def_ ## name) HT_def_ ## name = g_strdup(new_key);\

--- cut here ---

In this case I can use HT_def_GenericLanguage value as default key, so
module will be initialized with first supported language, and trying to
switch the language into unknown would be ignored (or switch back to
default language, what's better?)

I could provide patch for it, but I must be sure this modification will be
accepted. If not - I can provide patch for GenericDefaultLanguage.

ethanak
-- 
http://milena.polip.com/ - Pa pa, Ivonko!