Re: [XBoard-devel] gcc warnings

[h . g . muller]

> What IMO should be checked and fixed is the "may be used uninitialized"
> warnings:
>
> backend.c: In function 'LeftClick':
> backend.c:7306:8: warning: 'saveAnimate' may be used uninitialized in
> this function [-Wuninitialized]
>
> menus.c: In function 'MenuNameToItem':
> menus.c:886:50: warning: 'i' may be used uninitialized in this function
> [-Wuninitialized]

These two seem to be genuine bugs. The first I just introduced, and it
seems I only got away with it because the formally un-initialized memory
location still holds the value from the previous call to LeftClick, on the
down-click. (I was under the impression that this was a static variable,
but it is local!)

For i to be used uninitialized in menus.c, one would have to feed
MenuNameToItem a menu name without a period in it, which currently does
not happen in the code, but could happen if a user defines a key binding
in .Xresources with such an item name, so we'd better make it resistant to
that.

I will take care of these two when you are done with all other warnings.

> book.c: In function 'entry_from_file':
> book.c:391:19: warning: 'r' may be used uninitialized in this function
> [-Wuninitialized]
> book.c:400:12: note: 'r' was declared here
>
> xoptions.c: In function 'GenericPopUp':
> xoptions.c:994:62: warning: 'box' may be used uninitialized in this
> function [-Wuninitialized] xoptions.c:897:8: warning: 'forelast' may be
> used uninitialized in this function [-Wuninitialized] xoptions.c:995:46:
> warning: 'oldForm' may be used uninitialized in this
> function [-Wuninitialized]

The one in book.c is a red herring: a pointer to the variable is passed to
a routine that initializes it, but the compiler cannot see that. The
warning can be safely suppressed by just declaring as r=0. I guess the
compiler is formally right in that the GenericPopUp is not fool-proof; the
code relies on BoxEnd options in the Option list that describes a dialog
will not occur before a BoxBegin, and SAME_ROW options not being used as
first Option in a list. Since we only feed it lists defined in our own
code, we can guarantee this. So I think that here we should just silence
it too by assignment of NULL to all these variables in their declaration.
The routine is basically an interpreter to handle the dialog descriptions;
making it check the correctness of the discriptions seems like overdoing
it. Option lists from engines will never contain BoxBegin, BoxEnd or
SAME_ROW elements.