Re: -Wuninitialized issues

[Joe Buck <Joe dot Buck at synopsys dot COM>]

I wrote:

> > Just an off-the-wall idea: What if dereferencing an uninitialized variable
> > is considered a side effect?  Then that side effect must be preserved
> > unless it is unreachable.  Consider
> > 
> >        while (i > 0)
> >           i--;
> >        // no more uses of i.
> > 
> > Instead of throwing everything away, this would become
> > 
> > 	__check_initialized(i);
> > 
> > and we would still get the warning.

On Tue, Nov 01, 2005 at 12:20:40PM -0700, Jeffrey A Law wrote:

> I think that solves a subset of the stuff we're discussing, but
> I don't think it's general enough.  Consider a variable which is
> used in a statement and the result of that statement is never
> used.  ie
> 
> foo(int a)
> {
>   int i, x;
> 
>   x = a;
>   x += i;
> }

My suggestion would report an uninitialized access for i in this case.
There's a read of an uninitialized variable; it does not go away.

> Or unreachable code issues:
>   
> foo()
> {
>    int i;
> 
>    if (0)
>      i++;
> 
>    i = ...
>    more code...
> }

For this one, my suggestion would not report a warning: the uninitialized
access to i is not reachable.  But as a developer, I don't care: I want
uninitialized warnings to expose lurking bugs, not as a theoretical
exercise.

> In my mind it's more a matter of determining what behavior we
> want.  Once we've selected the desired behavior, achieving that
> behavior with the basic framework we've already got is pretty
> straightforward (unless we are determined to try and solve the
> halting problem :-)

If the halting problem raises its ugly head, I'm fine with false
positives.