<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:noqnoqneo@gmail.com" title="Artem Dergachev <noqnoqneo@gmail.com>"> <span class="fn">Artem Dergachev</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - CSA doesn't show all bugs in function"
href="https://bugs.llvm.org/show_bug.cgi?id=39134">bug 39134</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>WONTFIX
</td>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>noqnoqneo@gmail.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - CSA doesn't show all bugs in function"
href="https://bugs.llvm.org/show_bug.cgi?id=39134#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - CSA doesn't show all bugs in function"
href="https://bugs.llvm.org/show_bug.cgi?id=39134">bug 39134</a>
from <span class="vcard"><a class="email" href="mailto:noqnoqneo@gmail.com" title="Artem Dergachev <noqnoqneo@gmail.com>"> <span class="fn">Artem Dergachev</span></a>
</span></b>
<pre>Behaves correctly, i guess. Static Analyzer tries to prove that bugs can
actually occur when a specific execution path is taken, therefore the second
and the third bug here are treated as unreachable code, because the code above
them already contains undefined behavior. This doesn't prevent the analyzer
from finding any bugs, just delays finding some bugs until the previous bug is
fixed and the code is re-analyzed. A longer reply in
<a href="http://lists.llvm.org/pipermail/cfe-dev/2018-September/059552.html">http://lists.llvm.org/pipermail/cfe-dev/2018-September/059552.html</a>
We probably could have continued from the next statement after a UB is found,
in order to reduce the number of times the user has to spend re-running the
analyzer, but this would be very hard to even justify, let alone implement, and
the gain is very minor. Like, after 'free(c)' here, is 'c' freed? If not, maybe
we should diagnose a memory leak? If 'c' is treated as released but read later,
is it a use-after-free? If not, is the value read from it known to be same as
before or not? A checker-specific conservative behavior would need to be chosen
(in this case the correct answer would be to stop tracking the pointer in
MallocChecker and invalidate the contents and the reachable heap). Similar
questions would need to be asked for every checker, i.e. dozens of checkers
would need to be updated to support such restart feature and development of new
checkers would become harder. And even if it's done, in a lot of cases our
users would still eagerly discard newly found bugs as false positives because
they would notice that the bug is found immediately after a UB.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>