This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -Wuninitialized issues

On Tue, 2005-11-01 at 10:32 -0800, Joe Buck wrote:
> On Tue, Nov 01, 2005 at 11:17:52AM -0700, Jeffrey A Law wrote:
> > On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> > > To prevent losing location information for the warning, I had modified the 
> > > propagation engine to warn as it folded the expression away.
> > Possibly a useful thing to have, but I don't think we want to put
> > the burden of detecting uninitialized variables onto each 
> > optimizer :-)
> 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.
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;

Or unreachable code issues:
   int i;

   if (0)

   i = ...
   more code...

I think that picking one of the alternatives I outlined a few 
minutes ago will take us to a better place without resorting to
these kind of tricks.

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 :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]