<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 3, 2015 at 1:26 AM, Richard <span dir="ltr"><<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
In article <<a href="mailto:8761bjucor.fsf@fx.delysid.org">8761bjucor.fsf@fx.delysid.org</a>>,<br>
<span class=""> Mario Lang <<a href="mailto:mlang@delysid.org">mlang@delysid.org</a>> writes:<br>
<br>
> The List of potential checkers[1] posted recently contains this item,<br>
> which looked like a low hanging fruit, ideal for getting my feet wet<br>
> with matchers:<br>
><br>
> Undefined behavior: std::exit() is called to end the program during<br>
> the destruction of an object with static storage duration.<br>
><br>
> Source: C++11 3.6.1p4.<br>
><br>
> #include <cstdlib><br>
><br>
> class A {<br>
> public:<br>
> ~A() {<br>
> std::exit(1); // warn<br>
> }<br>
> };<br>
<br>
</span>Don't forget that you also need:<br>
<br>
static A a;<br>
<span class=""><br>
> I took this as an exercise, and was very surprised to see how easy this<br>
> was to do, and how little time it took to get done, given that my<br>
> experience with the AST prior to yesterday was virtually zero.<br>
<br>
</span>Yeah, it's fun playing with matchers and the AST!<br>
<span class=""><br>
> I have two questions:<br>
><br>
> 1. What would be an approriate name / category for this check?<br>
> 2. Is it worth submitting?<br>
<br>
</span>The answer to your second question is yes.<br>
<br>
I'm unsure if this should be in clang-tidy or the static analyzer.</blockquote><div><br></div><div>Proper implementation of this check needs some inter-function flow analysis (consider exit() called indirectly from a destructor of a global object) which may be non-trivial (if even possible) to implement statically. If you want to limit the scope of the check to direct calls to exit() from a global destructor, it should be easy to do in both clang-tidy and static analyzer. I suspect, that an ast matcher-based implementation could be easier to write, so it may be somewhat more convenient to add a check to clang-tidy.</div><div><br></div><div>Maybe adding a dynamic check to ubsan (-fsanitize=undefined) also makes sense. Richard, WDYT?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> I<br>
am still unclear which checks should go where. This one feels<br>
slightly more like the static analyzer should get it instead of<br>
clang-tidy.<br>
<br>
clang-tidy web page says:<br>
<br>
"clang-tidy is a clang-based C++ linter tool. Its purpose is to<br>
provide an extensible framework for diagnosing and fixing typical<br>
programming errors, like style violations, interface misuse, or<br>
bugs that can be deduced via static analysis."<br>
<br>
First, we don't have an automatic "fix" we can apply to correct the<br>
problem.<br>
<br>
Second, we are detecting undefined behavior, which isn't in the spirit<br>
of a style violation or interface misuse.<br>
<br>
Third, my gut feeling is that clang's static analyzer has more regular<br>
usage than clang-tidy and we'd like checks for undefined behavior to<br>
find their way into as many hands as possible.<br>
<br>
Finally, this is just my opinion so try and get some guidance from<br>
someone that is a regular contributor to the static analyzer for<br>
better advice :-).<br></blockquote><div><br></div><div>I have a feeling that static analyzer is more suitable for path-sensitive checks. Everything that is expressible in terms of AST is probably easier to implement in clang-tidy. Also, static analyzer doesn't have a way to provide automated fixes, so all checks that could provide fixes are usually more suitable for clang-tidy.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">--<br>
"The Direct3D Graphics Pipeline" free book <<a href="http://tinyurl.com/d3d-pipeline" target="_blank">http://tinyurl.com/d3d-pipeline</a>><br>
The Computer Graphics Museum <<a href="http://ComputerGraphicsMuseum.org" target="_blank">http://ComputerGraphicsMuseum.org</a>><br>
The Terminals Wiki <<a href="http://terminals.classiccmp.org" target="_blank">http://terminals.classiccmp.org</a>><br>
Legalize Adulthood! (my blog) <<a href="http://LegalizeAdulthood.wordpress.com" target="_blank">http://LegalizeAdulthood.wordpress.com</a>><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</font></span></blockquote></div><br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- </div><div class="gmail_extra">Alex</div></div>