[cfe-dev] PR17558 - Question about Uninitialized Variables
metafoo at gmail.com
Tue Jan 14 18:38:40 PST 2014
On Tue Jan 14 2014 at 5:56:08 PM, Michel Morin <mimomorin at gmail.com> wrote:
> Thanks for looking into the PR, Michael.
> Michael Bao wrote:
> > I'm looking at this bug report here:
> > http://llvm.org/bugs/show_bug.cgi?id=17558
> > I've narrowed down the issue ClassifyRefs::VisitCastExpr.
> I don't know the internals of clang, but I don't think the cast is
> For example, here is a test case without casting:
> #include <iostream>
> int main()
> int x;
> bool b = (&x == 0);
> std::cout << x << std::endl; // Missing "uninitialized" warning
> std::cout << b << std::endl;
The more general issue here is that if we see a local variable having its
address taken, we assume the variable escapes the analysis, and that we can
no longer reason about whether it is initialized. This is tricky to fix in
general; Michael's patch addresses one particular corner of this, but if
possible it'd be better to introduce a more holistic fix (addressing your
case, his, and lots of others).
To get a feeling for why this is tricky, we would like to diagnose:
int x; bool b = (&x == 0); f(b); return x;
... and ...
int x; bool b = &x; f(b); return x;
... but not ...
int x; int *b = &x; f(b); return x;
... because 'f' might initialize 'x'. 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.
We'd probably want to keep the analysis simple and local, however, so we'd
likely still miss the bug in this code:
int x; int *b = &x; if (cond) return x;
> Richard, I'd like to say thank you for fixing PR16054 (Missing
> "uninitialized" warning). Spotting such uninitialized bugs without
> running static analyzer is very helpful in a C primer course.
=) You're welcome!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev