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 _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers