[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gcc -fanalyze
From: |
Bruno Haible |
Subject: |
Re: gcc -fanalyze |
Date: |
Mon, 11 May 2020 21:17:39 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; ) |
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?".
* 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.
* 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].)
Bruno
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95044
- gcc -fanalyze, Bruno Haible, 2020/05/09
- Re: gcc -fanalyze, Kamil Dudka, 2020/05/12
- Re: gcc -fanalyze, Paul Eggert, 2020/05/12
- Re: gcc -fanalyze, Kamil Dudka, 2020/05/12
- Re: gcc -fanalyze, Paul Eggert, 2020/05/12
- Re: gcc -fanalyze, Kamil Dudka, 2020/05/13
- Re: gcc -fanalyze, Jeffrey Walton, 2020/05/13
- Re: reclaiming memory before exit, Bruno Haible, 2020/05/14
- Re: reclaiming memory before exit, Jeffrey Walton, 2020/05/14