[cfe-dev] -Wuninitialized

Daniel Dunbar daniel at zuster.org
Thu Mar 11 09:29:08 PST 2010


On Tue, Mar 9, 2010 at 2:39 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Mar 9, 2010, at 2:33 PM, Ted Kremenek wrote:
>
>> I am soliciting opinions about what to do about -Wuninitialied.  Clang currently doesn't implement it.  It does, however, have:
>>
>> (1) A simple flow-sensitive uninitialized values dataflow analysis in libAnalysis (currently usable as part of the static analyzer)
>>
>> (2) Path-sensitive checking for uninitialized values in the static analyzer.  This is far more precise than what GCC does at -Wuninitialized.
>>
>> I have heard numerous requests for -Wuninitialized, and other requests to have it run even at -O0 (which gcc does not do since -Wuninitialized is implemented as part of the optimizer).  The question is that given (2) should we implement -Wuninitialized at all?  If so, does (1) seem like a reasonable solution?
>>
>> More details about (1):
>>
>> (a) Not heavily performance optimized, but it that can be done over time
>>
>> (b) Doesn't check field values; does a simple flow-sensitive analysis of variables within a function
>>
>> (c) Sometimes GCC gets some amount of inter-procedural analysis with -Wuninitialized because of the inliner.  This is something we wouldn't consider doing in Clang.  For true inter-procedural uninitialized values checking, I prefer that to be (one day) in the static analyzer.
>
>
> I think that #1 could be very useful, particularly if it runs fast.  To me, it is more important that it behave predictably and catch the obvious cases than it is for it to be super tricky and catch uses in inlined functions etc like GCC tries to do.

Yes. IMHO, the compiler should
  (1) definitely support -Wuninitialized, at -O0 (I have heard from
numerous developers who compile at -O1 for this sole reason)
  (2) the implementation should be deterministic, and easily
explainable. That is, it should be easy to predict when writing code
whether the developer needs to explicitly initialize something because
it is a "tricky" case. Something along the lines of, all uses should
be statically dominated by a def or an escape, along all paths. This
is relatively cheap to compute, given the other existing
infrastructure.

Things like checking field values I see as value add.

 - Daniel

>
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>




More information about the cfe-dev mailing list