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.
