bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]