On 5/12/20 10:49 AM, Kamil Dudka wrote: > The problem is that such > false positives may easily turn out into true positives, as the code gets > changed, and nobody will notice it.
Sounds extremely unlikely here. It's never happened with coreutils as far as I know. For this particular case, this sounds more like a theoretical argument than a practical one. >> I doubt whether it's a good idea to apply downstream patches that mean you >> are running differently from everybody else. This is more maintenance work >> for you, > > It actually saves me work because it eases review of static analysis results. Why isn't it less work to build and analyze with '-Dlint'? Then you don't have to change the source code, so you won't have to adapt your patch to future releases. Is -Dlint avoided because it would break other tools? If so, how about if we change coreutils's '#ifdef lint' to '#ifdef GCC_LINT'? Then you could build and analyze with -DGCC_LINT. Emacs already does this, so there's good precedent. > We can only have subset of the bugs that everyone else has. I cannot image > a situation where initialization of otherwise uninitialized scalar variable > could introduce a new bug. I can. Perhaps the uninitialized variable has garbage in it that is typically nonzero, and a later bug in the program is triggered only by a rare combination of factors, one of which is that the variable must be zero. Of course there's no such bug in coreutils - but there's no bug of the flavor that you're imagining either. The point is that there's no proof that your bugs are a subset of everyone else's in this area.
