<div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 29 September 2016 at 09:52, Daniel Marjamäki <span dir="ltr"><<a href="mailto:Daniel.Marjamaki@evidente.se" target="_blank">Daniel.Marjamaki@evidente.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello!<br>
<br>
This sounds useful for those that wants to check CERT compliance.<br>
<br>
However if I just run clang-tidy as a complement to get extra checks .. then I don't want that clang compiler warnings are enabled and renamed "behind my back". Do you think we can avoid that?<br></blockquote><div><br></div><div>What do you mean? In case somebody enables the CERT checks, I think she is likely to be interested in all CERT checks. And right now there, when a check is already covered by a warning it is not added to clang tidy. So in order to get the best coverage on needs to review all of the warnings and enable them explicitly. I think it is much more convenient to just enable the CERT checks and you are good to go. Can you think of a use case where this is unintended behaviour? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Many static analyzer checkers has partial coverage of CERT rules also. For instance out-of-bounds, dereferencing null pointers, etc. I assume you would only alias checks that has full coverage?<br></blockquote><div><br></div><div>Yes, I think it we should only add alias to checks with full coverage. However, it would be great to document partial coverage somewhere. <br><br></div><div>Regards,<br></div><div>Gábor<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Imho it would be good to someday have MISRA, JSF, .. checks also. And I assume there is some overlap. so same warning could be aliased by both cert-* and misra-* etc.<br>
<br>
Best regards,<br>
Daniel Marjamäki<br>
<br>
..............................<wbr>..............................<wbr>..............................<wbr>........................<br>
Daniel Marjamäki Senior Engineer<br>
Evidente ES East AB Warfvinges väg 34 SE-112 51 Stockholm Sweden<br>
<br>
Mobile: <a href="tel:%2B46%20%280%29709%2012%2042%2062" value="+46709124262">+46 (0)709 12 42 62</a><br>
E-mail: <a href="mailto:Daniel.Marjamaki@evidente.se">Daniel.Marjamaki@evidente.se</a><br>
<br>
<a href="http://www.evidente.se" rel="noreferrer" target="_blank">www.evidente.se</a><br>
<br>
______________________________<wbr>__________<br>
Från: cfe-dev [<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.llvm.<wbr>org</a>] för Gábor Horváth via cfe-dev [<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>]<br>
Skickat: den 28 september 2016 09:44<br>
Till: Clang Dev; Alexander Kornienko; Aaron Ballman<br>
Ämne: [cfe-dev] [RFC][clang-tidy] Register warnings as check aliases<br>
<div class="HOEnZb"><div class="h5"><br>
Hi!<br>
<br>
I would like to propose that it should be possible to register compiler warnings as clang-tidy check aliases.<br>
<br>
As a motivating example, there is a CERT C++ secure coding rule: ERR54-CPP [1]<br>
<br>
This rule is covered by the clang warning: -Wexceptions<br>
<br>
So turning on this check in clang tidy would have two effects: turning on -Wexceptions and display the result of -Wexceptions as ERR54-CPP hits.<br>
<br>
In my opinion aliases like this would be a great usability improvement:<br>
- it would be easier to check the code against some coding guidelines.<br>
- it would be easier to check what rules are already covered.<br>
- it would be easier to find uncovered rules to implement.<br>
<br>
What do you think? Would you support a feature like that?<br>
<br>
Regards,<br>
Gabor<br>
<br>
[1]: <a href="https://www.securecoding.cert.org/confluence/display/cplusplus/ERR54-CPP.+Catch+handlers+should+order+their+parameter+types+from+most+derived+to+least+derived" rel="noreferrer" target="_blank">https://www.securecoding.cert.<wbr>org/confluence/display/<wbr>cplusplus/ERR54-CPP.+Catch+<wbr>handlers+should+order+their+<wbr>parameter+types+from+most+<wbr>derived+to+least+derived</a><br>
</div></div></blockquote></div><br></div></div></div>