Joe Buck - Re: -Wuninitialized issues (original) (raw)

This is the mail archive of the gcc@gcc.gnu.orgmailing 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]

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.

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