<p>New checkers which were contributed to the analyzer,
but have not passed a rigorous evaluation process,
are committed as "alpha checkers" (from "alpha version"),
- and are not enabled by default.
+ and are not enabled by default.</p>
- Ideally, only the checkers which are actively being worked on should be in
+ <p>Ideally, only the checkers which are actively being worked on should be in
"alpha",
but over the years the development of many of those has stalled.
- Such checkers need a cleanup:
- checkers which have been there for a long time should either
- be improved up to a point where they can be enabled by default,
- or removed, if such an improvement is not possible.
- Most notably, these checkers could be "graduated" out of alpha
- if a consistent effort is applied:
+ Such checkers should either be improved
+ up to a point where they can be enabled by default,
+ or removed from the analyzer entirely.
<ul>
<li><code>alpha.security.ArrayBound</code> and
<a href="https://en.wikipedia.org/wiki/Widening_(computer_science)">loop widening</a> support.
Additionally, it might be more promising to perform index checking based on
<a href="https://en.wikipedia.org/wiki/Taint_checking">tainted</a> index values.
- <i>(Difficulty: Medium)</i></p>
+ <p><i>(Difficulty: Medium)</i></p></p>
</li>
<li><code>alpha.cplusplus.MisusedMovedObject</code>
which have a well-defined semantics for use-after-move.
This property does not hold for STL objects, but is often the case
for custom containers.
- <i>(Difficulty: Medium)</i></p>
+ <p><i>(Difficulty: Medium)</i></p></p>
</li>
<li><code>alpha.unix.StreamChecker</code>
</ul>
</li>
- <li>Improved C++ support
+ <li>Improve C++ support
<ul>
<li>Handle aggregate construction.
<p><a href="https://en.cppreference.com/w/cpp/language/aggregate_initialization">Aggregates</a>
<code>CXXConstructExpr::CK_NonVirtualBase</code></a> branch of
<code>ExprEngine::VisitCXXConstructExpr()</code>
with proper support for the feature.
- <i> (Difficulty: Medium) </i></p>
+ <p><i>(Difficulty: Medium) </i></p></p>
</li>
<li>Handle constructors within <code>new[]</code>
large gains can be achieved by supporting only a few cases:
e.g. calling <code>.length()</code> on an empty
<code>std::string</code> always yields zero.
- <i>(Difficulty: Medium)</i><p>
+ <p><i>(Difficulty: Medium)</i></p><p>
</li>
<li>Enhance CFG to model exception-handling.
<p>Currently exceptions are treated as "black holes", and exception-handling
control structures are poorly modeled in order to be conservative.
This could be improved for both C++ and Objective-C exceptions.
- <i>(Difficulty: Medium)</i></p>
+ <p><i>(Difficulty: Hard)</i></p></p>
</li>
</ul>
</li>
This problem was
previously <a href="http://lists.llvm.org/pipermail/cfe-dev/2017-March/052864.html">discussed</a>
on the mailing list, but no solution was implemented.
- <i> (Difficulty: Medium) </i></p>
+ <p><i> (Difficulty: Medium) </i></p></p>
</li>
<li>Floating-point support.
and auditing existing code to make sure it doesn't
make incorrect assumptions (most notably, that <code>X == X</code>
is always true, since it does not hold for <code>NaN</code>).
- <i> (Difficulty: Medium)</i></p>
+ <p><i> (Difficulty: Medium)</i></p></p>
</li>
<li>Improved loop execution modeling.
but the <a href="https://en.wikipedia.org/wiki/Widening_(computer_science)">widening</a>
problem still remains open.
- <i> (Difficulty: Hard)</i></p>
+ <p><i> (Difficulty: Hard)</i></p></p>
</li>
<li>Basic function summarization support
enough to be a large improvement over conservative evaluation.
Such summaries could be obtained either syntactically,
or using a dataflow framework.
- <i>(Difficulty: Hard)</i><p>
+ <p><i>(Difficulty: Hard)</i></p><p>
</li>
<li>Implement a dataflow flamework.
a few dataflow analyses (most notably, liveness),
but they implemented in an ad-hoc fashion.
A proper framework would enable us writing many more useful checkers.
- <i> (Difficulty: Hard) </i></p>
+ <p><i> (Difficulty: Hard) </i></p></p>
</li>
<li>Track type information through casts more precisely.
checker is in charge of inferring a region's
dynamic type based on what operations the code is performing.
Casts are a rich source of type information that the analyzer currently ignores.
- <i>(Difficulty: Medium)</i></p>
+ <p><i>(Difficulty: Medium)</i></p></p>
</li>
</ul>
contributors are welcome to fix any of the outstanding
<a href="https://bugs.llvm.org/buglist.cgi?component=Static%20Analyzer&list_id=147756&product=clang&resolution=---">bugs</a>
in the Bugzilla.
- <i>(Difficulty: Anything)</i></p>
+ <p><i>(Difficulty: Anything)</i></p></p>
</li>
</ul>