>I would recommend to scan your code regularly with clang static
>analyzer. It's pretty easy, just execute "scan-build make" if you have
>clang installed. I have installed clang 3.5.0 on Linux.
>See http://clang-analyzer.llvm.org/scan-build.html .
>
>Some examples?
>
>In crypto /x509v3 /v3_purp.c line 294 it is called:
>
>xptable_free(xstandard + i);
>
>xptable_free() makes an free() on this pointer, but xstandard was not
>allocated with malloc(). See line 92:
>
>static X509_PURPOSE xstandard[] = {
>{X509_PURPOSE_SSL_CLIENT, X509_TRUST_SSL_CLIENT, 0,
>check_purpose_ssl_client, "SSL client", "sslclient", NULL},
>...
>};
>
>This is just an example...
>Sure, static analyzer contain false positives. Never the less, they
>should be used. Especially in security projects!
I suspect you underestimate a few things:
- the amount of legacy that remains in the tree,
- the number of steps it takes to improve code,
- the careful steps required to not make it worse,
- that there are a limited number of people
- who are working very hard,
- often more focused on other areas of more immediate importance,
- the volume of false positives that can occur,
- and that an obvious fix for a false positive can be disasterously
wrong.
Maybe you recognize some of these aspects, but not all of the aspects?
Have you ever worked in a source tree this large?
We can't even send "regular folk, non-expects" in to fix only "low
hanging fruit", because history has shown they soon make a wrong fix
in their zeal.
In general, you underestimate the effort involved. Otherwise, you
would be sending diffs to fix the bug. Instead, you report just the
issue. See how easy it is, and hard at the same time? The compiler
can tell you what is wrong, but it can't tell you how to fix it.
So thanks, but I don't know for what :-(
