[SystemSafety] A small taste of what we're up against

[Olwen Morgan]

A couple of days ago, a business associate asked me to look at the 
open-source C/C++ program checker cppcheck. One of his prospective 
clients thought it was more cost effective than pricier tools like 
QAC/QAC++ and Coverity. So I did a small experiment. Take a look at this 
short test program in C:


1:  #include <stdio.h>
2: // 5000000000 exceeds the greatest possible value of type unsigned 
int in both C implementations tested
3:  int main(void)
4:  {
5:      unsigned int u1 = 5000000000;
6:      unsigned int u2 = 5000000000u;
7:      unsigned int u3 = (unsigned int) 5000000000;
8:
9:     printf("\nu1 = %u, u2 = %u, u3 = %u\n", u1, u2, u3);
10:
11:     return 0;
12: }


Here are the diagnostics given by gcc v5.4.0, clang v.4.0 and cppcheck 
(v1.72?) respectively:

gcc: ... test-cppcheck-2.c:5:20: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]

           ... test-cppcheck-2.c:6:20: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]

clang:    ... test-cppcheck-2.c:5:20: warning: implicit conversion from 
'long' to 'unsigned int' changes value from 5000000000 to 705032704 
[-Wconstant-conversion]

           ... test-cppcheck-2.c:6:20: warning: implicit conversion from 
'unsigned long' to 'unsigned int' changes value from 5000000000 to 
705032704 [-Wconstant-conversion]

cppcheck: ZILCH !!!


Note also that the statement at line 7 should also be diagnosed since 
you cannot assume from the explicit type conversion that the programmer 
is actually aware of the truncation - he may have thought he'd written 
500000000 instead of 5000000000 everywhere.QAC - a mature and powerful 
static checker would, AFAI recall - maybe wrongly, produce a diagnostic 
for each of lines 5, 6 and 7

both gcc and clang-4.0 produce code that when run outputs: u1 = 
705032704, u2 = 705032704, u3 = 705032704

If you go to the web page for cppcheck (google for it - it's on 
sourceforge), you find that one of its design goals was to avoid false 
positive diagnostics. In so doing it performs worse than what are 
possibly the two most widely used C compilers around. The way to design 
static checking tools is so that they produce a *configurably low* level 
of false positives. Apparently, though, developers are more annoyed by 
false positive diagnostics than by the limitations of tools that do not 
produce them.

After avoiding errors in the first place, the best way to remove them is 
by checking for them as early and as effectively as possible. So, what 
hope is there in the face of this kind of lunacy? Is it surprising that 
once in a while you hear that "FOSS" really stands for "Full-on 
sh!t-spreading"?


Olwen