<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p><span style="font-size: 12pt;"> </span><br>
</p>
<div style="color: rgb(0, 0, 0);">
<div>
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>I had the same confusion while implementing the support for suppressing warnings because different teams would have different preferences. So I decided to implement both.</p>
<p>My implementation would take a YAML file which was generated by the clang static analyzer itself.</p>
<p><br>
</p>
<p><span style="font-size:12pt">There are several advantages of hashing-based method:</span></p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">1. It helps in tracking the history of reports by tracking just one file.</span><br>
</p>
<p>2. That YAML/JSON file can also be used by any IDEs to display a graphical view of control flow that led to the bug.</p>
<p>3. The suppression mechanism can be external to clang (if one choses to do so).</p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">4. The hashing based method is easier to implement and maintainable both for clang
source and the projects using it.</span><br>
</p>
<p><br>
</p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px"></span></p>
<div>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
The comment based approach is intrusive to the project and binds the project to clang static analyzer tool in that sense. It is difficult to maintain that functionality in the sense it relies heavily on the format of error report generated by the clang static
analyzer. Changing the error category or, moving the checker to another class would require a lot of change in the project. The one big advantage is that this approach enforces very active maintenance of the project.</p>
</div>
<div><br>
</div>
<p></p>
I think it will be good to have both kinds of support so that projects would have more flexibility.
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>-Aditya</div>
<div><br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of p23 power via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> Thursday, August 18, 2016 8:41 PM<br>
<b>To:</b> Gábor Horváth<br>
<b>Cc:</b> Clang Dev<br>
<b>Subject:</b> Re: [cfe-dev] Clang Static Analyzer: False Positive Suppression Support</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div>Suppress using comments (or pragma):</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div></div>
<div>Suppress using hashes</div>
</div>
</blockquote>
<div><br>
</div>
<div>At Sony I have had a number of customer requests for this feature, i.e. the analyzer to not output suppressed warnings. My preference is to feed in the hashes to clang, the reason for this is three fold. (1) From an investigation our customers do not want
to add suppression's as <a href="http://comments.in" id="LPlnk876142">comments.in</a> the source code. (2) Different teams may want to handle suppression's differently where many teams write/use the same code base (3) A developer may want to suppress everything
that is not theirs (only interested in new warnings that they have introduced) whilst the overnight build may want no suppressions (or limited suppressions). Using the comment/pragma method doesn't allow for configurability in different workflows.</div>
<div><br>
</div>
<div>Currently we provide tools that use the hashes stored in a simple json file (and suppress in the report viewer). I was thinking along the lines of passing this json file back into clang. A json file containing a simple list of hashes is relatively source
control friendly, though it is one more file to checkin (i.e. one file to store all hashes per project - obviously developers could decide to do one file per source file too).</div>
<div><br>
</div>
<div>I understand that some developers/teams may prefer the comment or pragma option. Would anybody object to support both methods? And are you open to using a json file as the input?</div>
<div><br>
</div>
<div>Regards,</div>
<div>Phillip</div>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>