<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">David has it correct. A good heuristic might be to say that if the switch has a default case, then we should assume values outside the enum cases are possible, but we don't currently do this.</div><div class=""><br class=""></div><div class="">Different codebases have different opinions on this, which is why Clang has both -Wswitch and -Wswitch-enum. The analyzer currently does not let you make such a decision.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 11, 2015, at 8:08 , David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">(Jordan - just cc'ing you because I don't know who's most active on the Static Analyzer these days)<br class=""><br class="">Yep - the Clang CFG used to make only one decision about edges, and mostly it made them conservatively to avoid one kind of false positive (eg: avoid diagnosing an uninitialized variable when a switch had a case for each enum value and each of those initialized the variable). But this conservative assumption has problems in the other direction as you noticed.<br class=""><br class="">After "goto fail; goto fail;" happened, Ted Kremenek improved the CFG somewhat to have optional/conditional extra edges in some way, and covered a few cases of this disparity, but the work is far from complete as demonstrated by cases like this.<br class=""><br class="">Not sure if anyone's looking/interested at the moment.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Sep 11, 2015 at 4:46 AM, Stephan Bergmann via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For a <a href="http://test.cc" class="">test.cc</a> input of<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
enum E1 { E1_0, E1_1 };<br class="">
enum E2 { E2_0, E2_1, E2_2 };<br class="">
enum class E3 { E3_0, E3_1 };<br class="">
int x;<br class="">
int f(E1 e1, E2 e2, E3 e3) {<br class="">
int n1 = x;<br class="">
switch (e1) {<br class="">
case E1_0: n1 = 0; break;<br class="">
case E1_1: n1 = 1; break;<br class="">
}<br class="">
int n2 = x;<br class="">
switch (e2) {<br class="">
case E2_0: n2 = 0; break;<br class="">
case E2_1: n2 = 1; break;<br class="">
case E2_2: n2 = 2; break;<br class="">
}<br class="">
int n3 = x;<br class="">
switch (e3) {<br class="">
case E3::E3_0: n3 = 0; break;<br class="">
case E3::E3_1: n3 = 1; break;<br class="">
}<br class="">
return n1 + n2 + n3;<br class="">
}<br class="">
</blockquote>
<br class="">
(where x is needed to work around heuristics in clang-tidy when not to warn about redundant initializations), calling (at least for a recent Clang trunk build)<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
clang-tidy -checks=clang-analyzer-deadcode.DeadStores <a href="http://test.cc" class="">test.cc</a> -- -std=c++11<br class="">
</blockquote>
<br class="">
causes clang-analyzer-deadcode.DeadStores warnings about the initializations of all three of n1, n2, n3. Apparently on the grounds that each switch statement is exhaustive.<br class="">
<br class="">
But from my understanding of the C++ standard, the ranges of enumeration values for E2, E3 are such that f can legally be called with values for e2, e3 that are not covered by the case branches of the respective switches, e.g. as<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
f(E1_0, E2(3), E3(std::numeric_limits<int>::max()));<br class="">
</blockquote>
<br class="">
Is this analysis deliberately unsound, on the assumption that objects of enumeration type take only enumerator values? If yes, is it deliberate to do so for both scoped and unscoped enumerations?<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>