>>> -Wuninitialized is a good warning, but since it's not 100%, [...]
>> Well, isn't the point to avoid uninitialized variables?
>> If you initialize it, haven't you solved the problem?
> I don't think so.  When a program "acts" on an unintialized variable,
> most often it's a case that the programmer didn't anticipate (ie. a
> bug).  If a the variable is initialized "just to shut the compiler
> up", there is no telling that the program will behave as intended
> when that dummy value is acted upon either.

Yes, if gcc is right, you are correct.  The problem is that gcc is
often wrong, and the variable cannot in fact be used uninitialized.
Several skeletal examples have been mentioned already by various
people.  In cases such as those, what do you recommend?  As far as I
can see the only options are (1) omit -Werror, (2) omit -Wuninitialized
(or use -Wno-uninitialized), or (3) add an initialization in a place
gcc can't miss.

I see a more general problem here, that being that -Werror is too
all-or-nothing.  I would like, for example, to have -Werror affect
warnings from -Wstrict-prototypes and -Wmissing-prototypes, but not
warnings from -Wuninitialized.  Perhaps someone should hack on gcc so
that in addition to -Wfoo and -Wno-foo, you can also say -Werr-foo,
which gives you -Wfoo plus -Werror for just -Wfoo warnings.  Then we
could use -Werr-all -Wuninitialized instead of -Wall -Werror.

In fact, I think I'll send mail to the gcc people suggesting this.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu