Skip to content

Commit 4ea0ac9

Browse files
Eliot-RoxberghEliot-Roxbergh
authored
Add more detailed result for CodeChecker
1 parent 0b279e5 commit 4ea0ac9

1 file changed

Lines changed: 52 additions & 44 deletions

File tree

‎README.md‎

Lines changed: 52 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,7 @@ Each binary has been tested with Valgrind, and only two have memory issues: posi
7070

7171
### Static Analysis Tools
7272

73-
__CodeChecker:__ 16 unique, 2 duplicates (semgrep). ~0/16 false positives
73+
__CodeChecker:__ 12 unique, 2 duplicates (semgrep). ~8/22 false positives (including 2 TP duplicates = matched twice via other codepath)
7474

7575
__Semgrep:__ 2 unique, 3 duplicates (codechecker 2, codeql 1). Additionally, it found ~11 false positives (I think), but this was still somewhat useful as it warns why these functions can be unsafe, although it does not know whether it is ok in this specific case.. might be annoying after a while.
7676

@@ -85,40 +85,48 @@ Although we get some less important warnings as we use --enable sensitive.
8585

8686
```
8787
-----------------------------------------------------------------------
88-
Checker name | Severity | Number of reports
88+
Checker name | Severity | Number of reports : True Positives (my approximation)
8989
-----------------------------------------------------------------------
90-
bugprone-narrowing-conversions | MEDIUM | 1
91-
unix.Malloc | MEDIUM | 1
92-
core.uninitialized.Branch | HIGH | 3
93-
cert-err34-c | LOW | 3
94-
clang-diagnostic-sometimes-uninitialized | MEDIUM | 4
95-
deadcode.DeadStores | LOW | 2
96-
unix.MallocSizeof | MEDIUM | 2
97-
unix.API | MEDIUM | 1
98-
core.CallAndMessage | HIGH | 1
90+
core.uninitialized.Branch | HIGH | 4 : 3
91+
core.CallAndMessage | HIGH | 1 : ALL
92+
clang-diagnostic-sometimes-uninitialized | MEDIUM | 4 : 2
93+
unix.Malloc | MEDIUM | 2 : ALL
94+
unix.MallocSizeof | MEDIUM | 2 : NONE
95+
unix.API | MEDIUM | 3 : 1
96+
bugprone-narrowing-conversions | MEDIUM | 1 : ALL
97+
cert-err34-c | LOW | 3 : ALL
98+
deadcode.DeadStores | LOW | 2 : 2
9999
-----------------------------------------------------------------------
100100
101101
Unique warnings
102-
4/4.c:109
103-
4/4.c:112
104-
4/4.c:192
105-
bit_manip.c:16
106-
bit_manip.c:17
107-
enum.c:26
108-
positives.c:44
109-
positives.c:45
110-
positives.c:66
111-
ptrs.c:73
112-
read_input.c:139
113-
read_input.c:144
114-
read_input.c:144 (again)
115-
read_input.c:172
116-
read_input.c:208
117-
read_input.c:58
102+
[MED.] 3/3.c:25 [unix.Malloc] TP? (might be problem if hits=0?) Use of memory after it is freed
103+
[MED.] 4/4.c:109 [...-sometimes-uninitialized] FP (???) Variable 'boards' is used uninitialized whenever 'if' condition is true
104+
[MED.] 4/4.c:112 [...-sometimes-uninitialized] FP? (same as above)
105+
[MED.] 4/4.c:126 [unix.API] ~TP (shouldn't really be a problem) Call to 'calloc' has an allocation size of 0 bytes
106+
[HIGH] 4/4.c:192 [core.uninitialized.Branch] TP (goto->free before declaration!) Branch condition evaluates to a garbage value
107+
108+
[MED.] enum.c:26 [bugprone-narrowing-conversions] TP, Narrowing conversion from 'double' to 'enum'
109+
[MED.] positives.c:44 [unix.Malloc] TP, Use of memory after it is freed
110+
[MED.] positives.c:45 [...-sometimes-uninitialized] TP, Variable 'data_2' is used uninitialized whenever 'if' condition is true
111+
[HIGH] positives.c:66 [core.uninitialized.Branch] TP, Branch condition evaluates to a garbage value
112+
[HIGH] ptrs.c:73 [core.CallAndMessage] TP, 2nd function call argument is an uninitialized value
113+
114+
[MED.] read_input.c:139 [...-sometimes-uninitialized] TP, variable 'nums' is used uninitialized whenever 'if' condition is true
115+
[MED.] read_input.c:144 [unix.API] FP, Call to 'malloc' has an allocation size of 0 bytes
116+
[MED.] read_input.c:144 [unix.API] FP, DUPLICATE (same as above)
117+
[MED.] read_input.c:144 [unix.MallocSizeof] FP? Result of 'malloc' is converted to a pointer of type 'int' ... incompatible with sizeof ('unsigned int')
118+
[MED.] read_input.c:208 [unix.MallocSizeof] FP? Result of 'malloc' is converted to a pointer of type 'int', which is incompatible with sizeof operand type 'unsigned int'
119+
[HIGH] read_input.c:172 [core.uninitialized.Branch] TP, Branch condition evaluates to a garbage value
120+
[HIGH] read_input.c:172 [core.uninitialized.Branch] TP, DUPLICATE (same as above)
121+
122+
[LOW] read_input.c:58 [cert-err34-c] TP, 'fscanf' used to convert a string to an integer value, ... will not report conversion errors (use 'strtol' instead) (1/3)
123+
[LOW] bit_manip.c:16 [deadcode.DeadStores] TP, minor, Value stored to 'bits_inverse' is never read
124+
[LOW] bit_manip.c:17 [deadcode.DeadStores] TP, minor, (same as above)
118125
119126
Detected by other tools (semgrep)
120-
read_input.c:151 //kind of duplicate, although funnily enough CodeChecker only warns on integers and fscanf, and Semgrep only explains why strings and fscanf are problematic (Semgrep warns on both, but fails to mention why integers are problematic)
121-
read_input.c:217
127+
//These two are some kind of duplicate, although funnily enough CodeChecker only warns on integers and fscanf, and Semgrep only explains why strings and fscanf are problematic (Semgrep warns on both, but fails to mention why integers are problematic)
128+
[LOW] read_input.c:151 [cert-err34-c] TP, 'fscanf' (2/3)
129+
[LOW] read_input.c:217 [cert-err34-c] TP, 'fscanf' (3/3)
122130
```
123131

124132
Interesting that we get a narrowing conversion warning not caught by -Wconversion, maybe enums is a special case?
@@ -135,24 +143,24 @@ For instance, a bit silly to always complain on the use of strlen or memcpy, but
135143

136144
```
137145
Unique
138-
[LOW] array.c:30 bcopy-1 //FP. Claims all memcpy is unsafe (but we know that destination is large enough). An alternative is memcpy_s from C11.
139-
[HIGH] read_input.c:295 vswscanf-1 //Bug! fscanf is unsafe if used with %s and no size limit, can overflow target buffer
140-
[HIGH] read_input.c:58 vswscanf-1
146+
[LOW] array.c:30 bcopy-1 //FP. Claims all memcpy is unsafe (but we know that destination is large enough). An alternative is memcpy_s from C11.
147+
[HIGH] read_input.c:295 vswscanf-1 //TP! fscanf is unsafe if used with %s and no size limit, can overflow target buffer
148+
[HIGH] read_input.c:58 vswscanf-1 //^
141149
[LOW] read_input.c:74 _gettc-1 //FP. Claims fgetc is unsafe ("need to manually check buffer boundries"), but we don't even use the returned value from fgets. Ok?
142-
[LOW] read_input.c:133 _gettc-1
143-
[LOW] read_input.c:194 _gettc-1
144-
[LOW] read_input.c:274 _gettc-1
145-
[LOW] read_input.c:31 _gettc-1
146-
[LOW] 3.c:25 _mbslen-1 //FP. Claims strlen is unsafe since it over-reads if not null-terminated. (there is strlen_s)
147-
[LOW] read_input.c:19 open-1 //FP? Claims on fopen is unsafe if an attacker can by symlink read or write to arbitrary file (we only open with read permissions)
148-
[LOW] read_input.c:265 open-1
149-
[LOW] read_input.c:184 open-1
150-
[LOW] read_input.c:123 open-1
150+
[LOW] read_input.c:133 _gettc-1 //^
151+
[LOW] read_input.c:194 _gettc-1 //^
152+
[LOW] read_input.c:274 _gettc-1 //^
153+
[LOW] read_input.c:31 _gettc-1 //^
154+
[LOW] 3.c:25 _mbslen-1 //FP. Claims strlen is unsafe since it over-reads if not null-terminated. (there is strlen_s)
155+
[LOW] read_input.c:19 open-1 //FP? Claims on fopen is unsafe if an attacker can by symlink read or write to arbitrary file (we only open with read permissions)
156+
[LOW] read_input.c:265 open-1 //^
157+
[LOW] read_input.c:184 open-1 //^
158+
[LOW] read_input.c:123 open-1 //^
151159
152160
Detected by other tools
153-
[HIGH] positives.c:22 _vstprintf-1 //Bug! Use snprintf(/sprintf_s) instead of sprintf.
154-
[HIGH] read_input.c:151 vswscanf-1 // Warns but does not describe why integers are a problem, which CodeChecker does see [cert-err34-c]
155-
[HIGH] read_input.c:217 vswscanf-1
161+
[HIGH] positives.c:22 _vstprintf-1 //TP! Use snprintf(/sprintf_s) instead of sprintf.
162+
[HIGH] read_input.c:151 vswscanf-1 // ~TP, Warns but does not describe why integers are a problem, which CodeChecker does see [cert-err34-c]
163+
[HIGH] read_input.c:217 vswscanf-1 // ^
156164
```
157165

158166
(apparently you can't see the warnings for more than 1 month if you don't pay them 40$/month, oops. Can run it locally though..)

0 commit comments

Comments
 (0)