Re: Undefined behavior sanitizing with Clang

[PrasannaKumar Muralidharan]

> 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.
>
>
> [*] 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.

Yes. I did mention about the false positives as it was high in count.
Clang static analyser did a very good job on another project (no false
positives) but it was a bit different with Octave. I feel Octave is a
good candidate to improve Clang static analyser - I do hope to report
the false positives to the Clang static analyser in future and see if
they find it useful.

- PrasannaKumar