Re: gcc -fanalyze

[Kamil Dudka]

On Monday, May 11, 2020 9:17:39 PM CEST Bruno Haible wrote:
> I agree with Paul, for three reasons:
> 
> * We, the developers, should decide how our programs look like. It's not
>   only a question of pride - even if that pride is only about having save a
>   'xorl %eax,%eax' instruction. It's a question about whether we use the
>   tools for our benefit, or we become slaves of the tools. I don't want
>   someone who reads diffseq.h to wonder "why did Paul initialize the
>   variables 'bxbest' and 'fxbest' with a value that ends up being
> overwritten anyway in all cases?".

This is a matter of taste.  When I read the code, I am asking myself different 
questions:

* How did Paul ensure that the variable is initialized on all code paths?

* Will it work in all possible corner cases?

* Does it still work as expected after change XY applied by someone else?

> * We use different compilers with data-flow analysis, and different static
>   analyzers occasionally. Sometimes GCC, sometimes clang, sometimes
> Coverity. Each of them has different false positives. It would be very ugly
> if we had to add source code annotations for different analyzers.

Sure.  Code that is readable by both people and static analyzers is certainly 
preferred over code annotations.

> * Gnulib is based on a bet that OSes will get better (more standards
> compliant) or die out. This enabled us to write code for the perfect POSIX
> compliant OS, and keep the workarounds outside of the mainline code. The
> bet succeeded: Our source code has few #ifs, and OSes like OSF/1 and HP-UX
> are dead. Similarly, we are betting that compilers' data-flow analysis will
> become better. Therefore we keep the IF_LINT invocations, knowing that at
> some point in the future the compilers that currently warn there will
> either have their data-flow analysis fixed, or will be dead. (I sincerely
> hope that GCC will fix its data-flow analysis; that's why I report bugs
> when I can [1], and Paul as well [2].)

So you assume that your code is perfect while the tools failing to analyze it 
properly are buggy.

Kamil

> Bruno
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95044