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
