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.
