Re: Undefined behavior sanitizing with Clang

[Philipp Kutin]

On Thu, Nov 14, 2013 at 6:58 PM, Rik <address@hidden> wrote:
> How does this differ from the sanitize log that PrasannaKumar sent to the
> list 3 days ago?

I looked at PrasannaKumar's log too. While it may expose interesting
issues, with static analysis you always have the possibility of false
positives. So you always have to look at the individual reports and
try to reconstruct what the analyzer is trying to complain at. IMO
Clang's static analysis has nicely annotated output, but the false
positive rate is too high [*]. The dynamic "sanitizers" on the other
hand always expose actual issues when they complain, namely constructs
that are undefined behavior according to the respective language
standards.

> He says that he used static analysis and it seems that you
> actually compiled and ran code, but you also said that compiling with -O0
> sometimes doesn't report issues.  Should we trust one report more than the
> other?

What I feared was false negatives, i.e. missed defects with the
sanitizers relative to earlier Clang versions. But that was rather
random speculation on my part. Also, I can now confirm that the output
is the same for an Octave build compiled with -O0 or -O1.

> Can you also upload the log a bug report so it doesn't get lost?

I don't want to say "I'll try" because I still have two of those
pending [**], but I'll see what I can do. Personally, I'd prefer to
resolve this quickly rather than opening a bug report because the
necessary changes and possible effects seem relatively local.

-----

[*] For example, sorting the list by path length and starting with the
shorter ones, even those ones contain false positives because the
analyzer isn't able to "see the whole picture". Such as in the report

API, Argument with 'nonnull' attribute passed null,
libinterp/corefcn/mex.cc, 1376, 5,

the analyzer doesn't see that "pi!=NULL iff val.pi!=NULL" and
concludes that memcpy may be called with a NULL source.

[**] One of those is my "promised" detailed analysis of the usability
of the classdef branch. I'm using it for a while now, and it's
certainly workable.

-----

While on the topic of code analyses, here's an nice blog article IMO,
which also introduces the two analysis "qualities" soundness and
completeness:
http://blog.frama-c.com/index.php?post/2013/04/26/Of-compiler-warnings-discussions


--Philipp