Re: gcc -fanalyze

[Kamil Dudka]

On Thursday, May 14, 2020 6:23:19 AM CEST Paul Eggert wrote:
> I doubt whether anybody will care about that "waste"; it's just a few
> instructions.

Good point.  I did not look at what merge_tree_destroy() and queue_destroy() 
really do and thought that their complexity was O(n).  Now I see that we can 
run them without any measurable performance penalty.  Thank you for pointing 
it out!

> 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.

That would mean to maintain suppression definitions for each tool separately, 
which is a good way to waste everybody's time.  Now I see that we can just 
build coreutils with -Dlint even for binary RPMs without any drawbacks.

> > 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.

Yes and we really want such programs to crash as early as possible, ideally
in our testing environment, or at least during beta testing at customer side.  
Our goal is to detect and fix such bugs before the software is released.

> 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.

Such a program can break at any time, even without adding the initializer
and even without rebuilding it from source code.  The sooner such bugs are 
discovered the better.

With your reasoning, we would not be able to use any hardening techniques 
because programs relying on undefined behavior could stop working.  And we 
would not be able to fix any bugs because programs relying on buggy behavior 
could stop working, etc.

Kamil