[Evolution-hackers] Uninitialized item.type in build_items (widgets/misc/e-filter-bar.c)

[Pavel Roskin <proski gnu org>]

Hello!

item.type can be used uninitialized in function build_items() in
widgets/misc/e-filter-bar.c

item.type is only initialized if type is 0 and there is a condition
described as:

/* Add a separator if there is at least one custom rule.  */

What's even more worrying is that item.type is not changed before
subsequent calls to g_array_append_vals(), whereas item.id and item.text
are changed.

Possible values of item.type are:

enum _ESearchBarItemType {
        ESB_ITEMTYPE_NORMAL,
        ESB_ITEMTYPE_CHECK,
        ESB_ITEMTYPE_RADIO,
};

ESB_ITEMTYPE_NORMAL and ESB_ITEMTYPE_CHECK are only referenced in a
switch statement in set_option() in widgets/misc/e-search-bar.c - they
are never assigned to anything.

However, item.type is set to ESB_ITEMTYPE_NORMAL implicitly in
build_items (0 is used instead of the symbolic constant).

set_option() has a catch-all default for item types other than those in
the enum.  That would work (with some luck!) for those uninitialized
values of item.type from build_items():

default:
       /* Fixme : this should be a normal item */
       item = gtk_radio_menu_item_new_with_label (group, str);
       group = gtk_radio_menu_item_get_group(GTK_RADIO_MENU_ITEM (item));
       break;

This issue was found by Valgrind, not by a compiler.  I could
misunderstand the logic, but Valgrind actually finds uninitialized data
being used.  I believe it's a serious problem that needs attention from
Evolution hackers.

-- 
Regards,
Pavel Roskin