On Tue, Apr 14, 2009 at 5:16 PM, Christopher Michael
<cpmicha...@comcast.net> wrote:
> Gustavo Sverzut Barbieri wrote:
>>
>> On Tue, Apr 14, 2009 at 4:09 PM, Andreas Volz <li...@brachttal.net> wrote:
>>>
>>> Am Fri, 10 Apr 2009 22:54:45 -0300 schrieb Gustavo Sverzut Barbieri:
>>>
>>>> On Fri, Apr 10, 2009 at 7:34 PM, Enlightenment SVN
>>>> <no-re...@enlightenment.org> wrote:
>>>>
>>>>> - now used Eina_List for storage (I hope I used it correct...)
>>>>> + Eina_List *l = NULL;
>>>>> + Evas_Object *o = NULL;
>>>>> +
>>>>> + // delete the list
>>>>> + for (l = xscreensaver_list; l; l = eina_list_next(l))
>>>>> + {
>>>>> + xscreensaver_list = eina_list_remove_list(xscreensaver_list,
>>>>> l);
>>>>> + }
>>>>> +
>>>>
>>>> please notice:
>>>>
>>>> l = NULL is dead assignment, the first thing you do later is to "l =
>>>> xscreensaver_list, so l = NULL is useless and will trigger an alert in
>>>> llvm/clang.
>>>
>>> Do you really think this is a "problem" that needs to be fixed? Would
>>> be the same here:
>>>
>>> static void
>>> _cb_disable_check_list(void *data, Evas_Object *obj)
>>> {
>>> Eina_List *list = (Eina_List*) data;
>>> Eina_List *l = NULL;
>>> Evas_Object *o = NULL;
>>>
>>> for (l = list, o = eina_list_data_get(l); l; l = eina_list_next(l),
>>> o = eina_list_data_get(l))
>>>
>>> {
>>> e_widget_disabled_set(o, !e_widget_check_checked_get(obj));
>>> }
>>> }
>>>
>>> For sure here you're right, but in general I prefer setting new
>>> pointers to NULL if the assignment is not in the next line. If someone
>>> else later changes the code otherwise this is a source for potential
>>> bugs. But here you're right and I could change it.
>>
>> you don't need to fix it now, maybe do in one go while fixing
>> llvm/clang warnings later. But initializing pointers to NULL or
>> variables to 0 is not good, if it was be sure that compilers would do
>> that automatically. It's easier to hide bugs with that, you'll make it
>> harder to valgrind to help you :-/
>>
> It should be noted tho that you can also run into cases of "variable may be
> used uninitialized" if you don't...which can also lead to issues.
very often these warnings are real errors, so more useful than bad.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
