[cfe-users] Running 'scan-build' in SRD's test cases (NIST)
Edoardo P.
ed0.88.prez at gmail.com
Thu Feb 20 13:25:08 PST 2014
I forgot to add more info regarding the not detected int divisions:
the only correctly warned parts are for very simple cases, like this:
int x = 0; ... int y = 100 / x;
and the modulo variant. The other ones, which are not detected, assign x
with:
- atoi (used when converting a string returned by socket functions or fgets)
- fscanf
- rand
And all the variants of such functions. The examples for fscanf and rand
are simple:
fscanf variant:
void f_fscanf()
{
int data;
fscanf(stdin, "%d", &data);
/* POTENTIAL FLAW: Possibly divide by zero */
printIntLine(100 / data);
}
rand variant:
void f_rand()
{
int data;
data = rand();
/* POTENTIAL FLAW: Possibly divide by zero */
printIntLine(100 / data);
}
in the test suite, rand is replaced with a macro, RAND_32(), defined as:
from testcasesupport/std_testcase.h:
/* rand only returns 15 bits, so we xor 3 calls together to get the full
result (13 bits overflow, but that is okay) */
#define RAND32() ((rand()<<30) ^ (rand()<<15) ^ rand())
(I'd truncate the first rand() to the first 2 bits before shifting it to
30th bit position, just to avoid overflow ...)
The 'itoa' case is more complex. Imho, the analyzer, before reporting the
warning, should check that there can be a possibility that the string
argument will be converted to 0. I hope it's possible with the current
analyzer architecture...
Cheers,
Edward-san
2014-02-20 15:26 GMT+01:00 Edoardo P. <ed0.88.prez at gmail.com>:
> Hi Lucas:
>
>
>> I am doing today a script to run all test case in Juliet with Clang and
>> generate a report (CSV file), when a finished this i will send you the
>> results.
>
>
> Please do.
>
>
>> But a run manually and clang can find only 54 weaknesses in a
>> total of 1476 files (into testcases/CWE369_Divide_by_zero, including s01
>> and s02 directories).
>>
>>
> I can confirm that. In IRC I discussed with some llvm devs about the need
> to report the float division by zero (Standard C/C++ says it's undefined
> behavior, but Annex F implicitly allows it, thanks to IEEE 754). I have an
> idea: add a new static analyzer option which allows or disallows optional
> features, including the optional Annexes. That would help a lot imho.
>
> Cheers,
> Edward-san
>
>
>> On Tue, 2014-02-18 at 16:19 +0100, Edoardo P. wrote:
>> > Hi, Lucas, Jordan:
>> >
>> >
>> > About the division by zero checking, I run this:
>> >
>> >
>> > scan-build --use-analyzer /usr/bin/clang -o buildres/ clang -c -I
>> > testcasesupport -DOMITGOOD
>> >
>> testcases/CWE369_Divide_by_Zero/s02/CWE369_Divide_by_Zero__int_zero_divide_01.c
>> -o /dev/null
>> >
>> >
>> > and I get the warnng:
>> >
>> >
>> testcases/CWE369_Divide_by_Zero/s02/CWE369_Divide_by_Zero__int_zero_divide_01.c:30:22:
>> warning: Division by zero
>> > printIntLine(100 / data);
>> > ~~~~^~~~~~
>> >
>> >
>> > So, Lucas, which file was failing for you?
>> >
>> >
>> > Regarding the experience, here it is what I gathered till now:
>> >
>> > I created a very huge file_list.txt, containing the source files to
>> > compile (I used 'find -name *.c*' in the juliet directory), then
>> > filtered away the 'main\.c', 'main_linux\.c' and 'testcasesupport'
>> > files (grep -v), which have nothing to check, then I sorted the list
>> > by CWE number (I had to do manual sorting because I couldn't manage to
>> > sort, for example, CWE15_* and CWE114_* correctly).
>> >
>> > Since I can't check for win32-only tests (I'm using linux), I filtered
>> > them via 'grep -v w32' and 'grep -v wchar_t' (some tests require a
>> > 'fopen'-like function with wchar_t string, which seems to be exclusive
>> > to win32).
>> >
>> >
>> > Regarding the per-translation-unit analysis, some files are, indeed,
>> > separated sources for a program, so I didn't hesitate to filter them
>> > with these patterns, according to the manual: "[abcdeBG]\.c" and
>> > "good1" (last was associated with a 'bad' file, which was already
>> > filtered).
>> >
>> >
>> > With this file_lists.txt, I run the static analyzer only for the false
>> > positives, with this command:
>> >
>> > < file_list.txt xargs -n 1 scan-build --use-analyzer /usr/bin/clang
>> > -disable-checker deadcode.DeadStores -o buildres/ clang -c -I
>> > testcasesupport -DOMITBAD -o /dev/null > /dev/null 2> warns.txt
>> >
>> >
>> > so, it checks all the files in the file list, saves the results in
>> > buildres and reports the warnings in warns.txt file, ignoring the
>> > DeadStores warns because they're reported a lot often.
>> >
>> >
>> > Well, there are tons of false positives, caused by the flow variants
>> > which involve global and static variables, shadow variables usage,
>> > etc.
>> >
>> >
>> > To the devs, I'd like to know which CWE are you interested, from the
>> > list I attached on that email:
>> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035113.html .
>> >
>> >
>> > About the results, if I have more time, I'll post some of them.
>> >
>> >
>> >
>> > 2014-02-18 2:05 GMT+01:00 Lucas Kanashiro
>> > <kanashiro.duarte at gmail.com>:
>> > Thanks Jordan!
>> >
>> > Could you leave me updated on the matter? I am so interested
>> > in this,
>> > and if it is necessary and possible i want to help to solve
>> > the
>> > potential issue.
>> >
>> > Edward, can you tell us your experience with Clang and Juliet
>> > Test
>> > Suite?
>> >
>> >
>> > On Mon, 2014-02-17 at 09:43 -0800, Jordan Rose wrote:
>> > > Hi, Lucas. The analyzer currently runs a
>> > per-translation-unit analysis, so it misses some bugs that
>> > whole-program analysis may be able to catch. I'm guessing
>> > that's the reason it's unable to catch this particular issue.
>> > >
>> > > In general, the analyzer is set for reasonably fast
>> > turnaround (depending on the size of the project, of course),
>> > so it also might not do a fully precise interprocedural
>> > analysis if the state space gets too big. I'd have to see the
>> > particular test case to tell what's going on here.
>> > >
>> > > I did see that Edward (CC'd) wanted to try bringing in the
>> > Juliet Test Suite for the analyzer, but neither I nor Ted (the
>> > lead on the analyzer) have gotten the chance to sit down and
>> > look at what this would actually entail. It's possible he's
>> > encountered similar issues, however.
>> > >
>> > > Jordan
>> > >
>> > >
>> > > On Feb 15, 2014, at 5:58 , Lucas Kanashiro
>> > <kanashiro.duarte at gmail.com> wrote:
>> > >
>> > > > I am trying to running 'scan-build' in Juliet suite
>> > testcase v1.2 (NIST
>> > > > indication) to catch some bugs of 'Division by zero' (CWE
>> > 369) and I
>> > > > can't do it, the scan-build can't show me the existing
>> > bugs. Did someone
>> > > > try to do it yet?
>> > > >
>> > > > I have a doubt that scan-build can identify a bug of
>> > division by zero in
>> > > > this case (when parameter denominator is zero):
>> > > >
>> > > > int divide (int denominator) {
>> > > > return 10/denominator;
>> > > > }
>> > > >
>> > > > Can someone help me? Is this a deficiency of scan-build?
>> > Can scan-build
>> > > > identify the bugs in Juliet suite?
>> > > >
>> > > > Thanks in advance!
>> > > >
>> > > > --
>> > > > Lucas Kanashiro Duarte
>> > > > Engenharia de Software - FGA/UnB
>> > > > kanashiro.duarte at gmail.com
>> > > >
>> > > > _______________________________________________
>> > > > cfe-users mailing list
>> > > > cfe-users at cs.uiuc.edu
>> > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
>> > >
>> >
>> > --
>> > Lucas Kanashiro Duarte
>> > Engenharia de Software - FGA/UnB
>> > kanashiro.duarte at gmail.com
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Mathematics is the language with which God has written the universe.
>> > (Galilei)
>>
>> --
>> Lucas Kanashiro Duarte
>> Engenharia de Software - FGA/UnB
>> kanashiro.duarte at gmail.com
>>
>>
>
>
> --
> Mathematics is the language with which God has written the universe.
> (Galilei)
>
--
Mathematics is the language with which God has written the universe.
(Galilei)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20140220/b962725f/attachment.html>
More information about the cfe-users
mailing list