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.
