Gustavo Sverzut Barbieri wrote:
> On Tue, Apr 14, 2009 at 6:05 PM, Christopher Michael
> <cpmicha...@comcast.net> wrote:
>> Gustavo Sverzut Barbieri wrote:
>>> 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.
>>>
>> Exactly...so IMO it would be better to leave them initialized to NULL (as
>> it's certainly not 'hurting' anything), plus it's safer...regardless of what
>> clang says.
>
> Ok, my last email, do what you wish as this is not critical, but it's
> not *safer*. This is a false claim. it's bad programing habit and will
> make debug with valgrind harder. Just like zeroing pointers and memory
> before freeing (you loose track of the problem root).
>
Ok, so you are saying that declaring variables (but potentially never
initializing them) is better ? Find that very hard to believe...
dh
------------------------------------------------------------------------------
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
