bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc -fanalyze


From: Paul Eggert
Subject: Re: gcc -fanalyze
Date: Thu, 14 May 2020 20:11:40 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/14/20 1:34 AM, Kamil Dudka wrote:

> Now I see that we can just 
> build coreutils with -Dlint even for binary RPMs without any drawbacks.

Good, and that also means you don't need the coreutils-8.32-if-lint.patch that
you mentioned earlier. One less thing to maintain.

> Such a program can break at any time

Yes and no. The program can break if you run it on a different platform with
different undefined behavior. But often in practice it won't break if you keep
running it the same way you ran it before, and often it won't break even if you
substitute a different platform.

All I was trying to do is respond to your your earlier statement "I cannot
imagine a situation where initialization of otherwise uninitialized scalar
variable could introduce a new bug." Such initialization definitely can break
programs in a practical sense (i.e., users see a program crash where it
previously worked), even though (as you note) in a language-lawyer sense the
program was buggy already and users were just lucky that it happened to
invariably work for them in practice.

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

My reasoning doesn't lead that way at all. I was merely responding to a
statement about imagining situations. The situation I imagined is rare enough
that it can't reasonably justify avoidance of all hardening techniques.

Really, I'm not far from your position. See my October 2018 comment
<https://lists.gnu.org/archive/html/bug-gnulib/2018-10/msg00045.html> where I
write "Long ago I became wary of '#ifdef lint' code...". It's just that I'm not
as willing to sacrifice other important software engineering objectives merely
to pacify flawed static checkers.



reply via email to

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