Static analyzers results on musl

[Alexander Monakov <amonakov@ispras.ru>]

Hello,

From reading recent archives, it appeared to me there was some interest in
applying source code analysis tools to musl.  My co-workers helped me run a
couple of tools on musl, so here are the results.

Szabolcs kindly assisted with hosting Clang Analyzer results at

  http://port70.net/~nsz/musl/clang-2013-10-04/  

The analyzer was run on today's sources (commit 38a0a4d).  The build with
make -j4 was interrupted at some point during building PIC objects; I presume
at that point all non-PIC code was built, and the analyzer saw all source
code, except maybe some #ifdef SHARED sections.

My take on those:
 - 2 sizeof mismatch warnings make sense
 - 19+1 "dead code" warnings are helpful
 - "Out-of-bound array access" in glob.c appears to be a false positive (?)
 - There are many "garbage"/"undefined" warnings where the variable in
   question is passed to a syscall by reference and expected to be initialized
   there, unless error is signalled; it's quite unfortunate to have many false
   positives like that
 - I have not attempted to investigate "dereference of null" warnings


I also have results from another static analysis tool developed internally
were I work.  Here's a few hand-picked additional warnings.  I ran the tool
without updating git first, so the tree was from September 9 (commit ff4be70).
Sorry about that.

setenv.c:21  malloc return value not checked

getspnam_r.c  I wonder if there's a window between opening the file and
pthread_cleanup_push where the handle would leak? (this is not what the tool
flagged)

vfprintf.c:664
vfwprint.c:354  va_end not called on error return path

regcomp.c:767
regcomp.c:807  sizeof mismatch; don't know why not flagged by clang

getifaddrs.c:92  the code trusts the kernel that the fifth token would not be
longer than IFNAMSIZ :)

There are a few warnings that return value of .*nl_langinfo.* is not checked
for NULL before use; presumably that is by design.

Hope that helps.

Alexander