[cfe-dev] PR17558 - Question about Uninitialized Variables

Michael Bao mike.h.bao at gmail.com
Thu Jan 16 15:27:49 PST 2014

Got an implementation here and it passes all the tests! :) (Actually
had to change one test since it was relying on (void)&x marking 'x' as
being initialized).

So cases like:

  int x; (void)&x; return x;
  int x; int* y = &x; return x;
  int x; bool b = (&x == 0); return x;
  int x; bool b; b = &x; foo(b); return x;

Will give an "uninitialized" warning on the return.

While cases like
  int x; int* y = &x; foo(y); return x;
  int x; int *y = &x; int *z = y; return x;

Will not show an uninitialized warning.

More technical details:

1) When I encounter a "Address Of" operator, I mark the child
DeclRefExpr as being in a "Pending" state. If it remains in the
pending state, then we treat it the same way as we would an "Ignore"
and Clang will identify the variable as being uninitialized (provided
nothing else is done with the variable).

2) If the "Address Of" is assigned to a non-pointer variable, then we
mark the child DeclRefExpr as being in the "Pending" state.

3) If the "Address Of" is assigned to a pointer variable, then we mark
the child DeclRefExpr as being in the "WaitForRef" state. In this
case, we will store it for later processing and store which variable
it was assigned to. Along the way, if the pointer is used, we will
make sure to remember that it was used so we can later mark the
"Address Of" variable as being potentially initialized.

4) After the initial visits using ClassifyRefs, I do one last pass
through the stored "Address Of" expressions that were assigned to
pointers and check to see if those pointers were used and change
classifications as necessary.

If this general idea/direction/functionality looks good, I'll write up
some tests and send it over to cfe-commits.

On Thu, Jan 16, 2014 at 1:28 AM, Michel Morin <mimomorin at gmail.com> wrote:
> Richard Smith wrote:
>> This is tricky to fix in general;
>> Michael's patch addresses one particular corner of this,
> Ah, now I understand what Michael tried to do.
>> In general, we would like to look at the context in which '&x' appears,
>> and determine if that context could possibly store through the pointer
>> or save it somewhere.
> Such contextual analysis would be nice ;)
> FWIW, gcc can warn about uninitialized variables whose address are taken
> only when optimization is enabled.
> (Without optimization, gcc behaves similarly to clang.)
> Regards,
> Michel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uninitialized-warning.patch
Type: application/octet-stream
Size: 9620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140116/ae879f79/attachment.obj>

More information about the cfe-dev mailing list