<div dir="ltr"><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">However, if the goal is to have the tests<br>because you would like to make efforts to have the compiler diagnose<br>their cases properly, that's far more interesting and a good reason to<br>bring in the tests.</blockquote><div><br></div><div>That's exactly my intention. Improving the static analyzer to detect these cases, that will be interesting.</div><div>placeholder text</div><div><br></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">If the other tests are not clearly licensed, we<br>should try to get NIST to clarify the license of them before<br>inclusion.</blockquote></div><div><br></div><div>That sounds like the best idea, as a government agency, they almost certainly have lawyers.</div><div><br></div><div>I think the next step is to integrate the working (error correctly diagnosed) tests, only those that are obviously in the public domain, and propose them as a big batched patch. This shouldn't itself be controversial. </div><div><br></div><div>How exactly do I submit a patch? I see that the LLVM developer policy says to send it to the mailing list (cfe-commits), but I also see that <a href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151214/145026.html">Phabricator comes into this somewhere</a>?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Sincerely,<br>Alexander Riccio<br>--<br>"Change the world or go home."<div><a href="http://about.me/ariccio" target="_blank">about.me/ariccio</a></div><div><a href="http://about.me/ariccio" target="_blank"><br></a></div><div>If left to my own devices, I will build more.</div><div>⁂<br></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Dec 10, 2015 at 4:04 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Dec 7, 2015 at 9:50 PM, <Alexander G. Riccio> via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> First time Clang contributor here,<br>
><br>
> I'd like to add the "C Test Suite for Source Code Analyzer v2", a<br>
> relatively small test suite (102 cases/flaws), some of which Clang<br>
> doesn't yet detect*. See link at bottom.<br>
><br>
> Immediate questions:<br>
> 0. Does the Clang community/project like the idea?<br>
<br>
</span>I've included a few other devs (CCed) to get further opinions.<br>
<br>
I like the idea of being able to diagnose the issues covered by the<br>
test suite, but I don't think including the test suite by itself is<br>
particularly useful without that goal in mind. Also, one question I<br>
would have has to do with the licensing of the tests themselves and<br>
whether we would need to do anything special there.<br>
<span class=""><br>
> 1. What's the procedure for including new tests? (not the technical,<br>
> but the community/project).<br>
<br>
</span>Getting the discussion going about the desired goal (as you are doing)<br>
is the right first step.<br>
<span class=""><br>
> 2. How do I include failing tests without breaking things? Some of<br>
> these tests will fail - that's why I'm proposing their inclusion - but<br>
> they shouldn't yet cause the regression testing system to complain.<br>
<br>
</span>Agreed, any test cases that are failing would have to fail gracefully.<br>
I assume that by failure, you mean "should diagnose in some way, but<br>
currently does not". I would probably split the tests into two types:<br>
one set of tests that properly diagnose the issue (can be checked with<br>
FileCheck or -verify, depending on the kind of tests we're talking<br>
about), and one set of tests where we do not diagnose, but want to see<br>
them someday (which can be tested with expect-no-diagnostics, for<br>
example). This way, we can ensure test cases continue to diagnose when<br>
we want them to, and we can be alerted when new diagnostics start to<br>
catch previously uncaught tests. This is assuming that it makes sense<br>
to include all of the tests at once, which may not make sense in<br>
practice.<br>
<span class=""><br>
> 3. How does Clang handle licensing of third party code? Some of these<br>
> tests are clearly in the public domain (developed at NIST, says "in<br>
> the public domain"), but others are less clearly licensed.<br>
<br>
</span>Oh look, you asked the same question I asked. ;-) If the tests are in<br>
the public domain and clearly state as such, I think we can go ahead<br>
and include them. If the other tests are not clearly licensed, we<br>
should try to get NIST to clarify the license of them before<br>
inclusion. Depending on the license, we may be able to include them<br>
under their original license. If we cannot clarify the license, I<br>
would guess that we simply should not include those tests as part of<br>
our test suite. Note: I could be totally wrong, IANAL. :-)<br>
<span class=""><br>
> Should the community accept that testsuite, and I successfully add<br>
> that test suite, then I'd like to step it up a bit, and include the<br>
> "Juliet Test Suite for C/C++". "Juliet" is a huge test suite by the<br>
> NSA Center for Assured Software & NIST's Software Assurance Metrics<br>
> And Tool Evaluation project, which has 25,477 test cases (!!) for 118<br>
> CWEs. I don't think any other open source compiler could compete with<br>
> Clang after this. There's a ton of literature on the "Juliet" suite,<br>
> and listing it here is not necessary.<br>
><br>
> This project would be my first Clang contribution :)<br>
><br>
> Personally, I'm interested in static analysis, and this is the first<br>
> step in understanding & improving Clang's static analysis<br>
> capabilities.<br>
><br>
> I have some ideas on how to detect the currently undetected bugs, and<br>
> I'm curious to see where things lead.<br>
<br>
</span>Adding the tests by themselves is not necessarily interesting to the<br>
project unless they exercise the compiler in ways it's not currently<br>
being exercised. So just having tests for the sake of having the tests<br>
is not too useful (IMO). However, if the goal is to have the tests<br>
because you would like to make efforts to have the compiler diagnose<br>
their cases properly, that's far more interesting and a good reason to<br>
bring in the tests.<br>
<br>
One possible approach if you are interested in having the compiler<br>
diagnose the cases is to bring the tests in one at a time. Start with<br>
the initial batch of "these are diagnosed properly", then move on to<br>
"this test is diagnosed properly because of this patch." Eventually<br>
we'll get to the stage where all of the tests are diagnosed properly.<br>
<span class=""><br>
> Secondary questions:<br>
> 1. How should I break the new tests up into patches? Should I just<br>
> whack the whole 102 case suite into a single patch, or a bunch of<br>
> smaller ones?<br>
<br>
</span>See comments above.<br>
<span class=""><br>
> 2. How does the Clang/LLVM static analysis testing infrastructure<br>
> work? I'm going to have to figure this out myself anyways, but where<br>
> should I start? Any tips on adding new tests?<br>
<br>
</span><a href="http://clang-analyzer.llvm.org/checker_dev_manual.html" rel="noreferrer" target="_blank">http://clang-analyzer.llvm.org/checker_dev_manual.html</a><br>
<br>
Another good place for some of these checkers may be clang-tidy, or<br>
the compiler frontend itself. It's likely to depend on case-by-case<br>
code patterns.<br>
<br>
<a href="http://clang.llvm.org/extra/clang-tidy/" rel="noreferrer" target="_blank">http://clang.llvm.org/extra/clang-tidy/</a><br>
<br>
Thank you for looking into this!<br>
<br>
~Aaron<br>
<span class=""><br>
><br>
> *If I remember correctly,<br>
> <a href="https://samate.nist.gov/SRD/view_testcase.php?tID=149055" rel="noreferrer" target="_blank">https://samate.nist.gov/SRD/view_testcase.php?tID=149055</a> passes<br>
> analysis without complaint. I manually spot checked a very small<br>
> number of tests.<br>
><br>
> "C Test Suite for Source Code Analyzer v2" (valid code):<br>
> <a href="https://samate.nist.gov/SRD/view.php?tsID=101" rel="noreferrer" target="_blank">https://samate.nist.gov/SRD/view.php?tsID=101</a><br>
> "C Test Suite for Source Code Analyzer v2" (invalid code):<br>
> <a href="https://samate.nist.gov/SRD/view.php?tsID=100" rel="noreferrer" target="_blank">https://samate.nist.gov/SRD/view.php?tsID=100</a><br>
><br>
> "Juliet Test Suite for C/C++" (files):<br>
> <a href="https://samate.nist.gov/SRD/testsuites/juliet/Juliet_Test_Suite_v1.2_for_C_Cpp.zip" rel="noreferrer" target="_blank">https://samate.nist.gov/SRD/testsuites/juliet/Juliet_Test_Suite_v1.2_for_C_Cpp.zip</a><br>
> "Juliet Test Suite for C/C++" (docs):<br>
> <a href="https://samate.nist.gov/SRD/resources/Juliet_Test_Suite_v1.2_for_C_Cpp_-_User_Guide.pdf" rel="noreferrer" target="_blank">https://samate.nist.gov/SRD/resources/Juliet_Test_Suite_v1.2_for_C_Cpp_-_User_Guide.pdf</a><br>
><br>
><br>
> Sincerely,<br>
> Alexander Riccio<br>
</span>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>