Re: gcc -fanalyze

[Paul Eggert]

On 5/13/20 5:49 AM, Kamil Dudka wrote:

>     http://git.savannah.gnu.org/cgit/acl.git/commit?id=33f01b5d

Yes, I have no doubt that valgrind etc. helps find problems in both coreutils
and elsewhere. But that's not the issue here.

>> Why isn't it less work to build and analyze with '-Dlint'?
> 
> Using it for static analyzers only is not an option.

Right, and I wasn't suggesting that option. I was suggesting that you build
production with -Dlint (or with -DGCC_LINT; we could do that easily), and that
you statically analyze the same way.

> Building RPMs with -Dlint would mean performance 
> penalty because some programs (e.g. sort) would explicitly release complex 
> data structures just before exit, which is wasteful.

I doubt whether anybody will care about that "waste"; it's just a few
instructions. But if that's the issue, we could easily remove the 'free' at the
end of 'sort'. As I understand it, the 'free' is there only to pacify valgrind,
and it's better to use a valgrind suppression file to deal with that sort of
pacification.

> Relying on undefined behavior is not an option.

Of course it's not an option in reliable software. That's not the point. My
point was that the program could have the bug I mentioned, such that adding an
initialization of a variable to zero makes the program crash when the program
used to work, even though the *reason* the program formerly worked was because
it happened to rely on undefined behavior.

In other words, substituting defined for undefined behavior can introduce an
observable bug into a program that previously worked on platform X. So one
cannot assume that because a program worked in practice without initializing a
variable to zero, the program must continue to work in practice after you add
the initialization.