On Wed, May 13, 2020 at 8:49 AM Kamil Dudka <kdu...@redhat.com> wrote: > On Tuesday, May 12, 2020 11:58:49 PM CEST Paul Eggert wrote: > > On 5/12/20 10:49 AM, Kamil Dudka wrote: > ... > > >> I doubt whether it's a good idea to apply downstream patches that mean > > >> you > > >> are running differently from everybody else. This is more maintenance > > >> work > > >> for you, > > > > > > It actually saves me work because it eases review of static analysis > > > results. > > Why isn't it less work to build and analyze with '-Dlint'? > > Using it for static analyzers only is not an option. We need to analyze the > code that is going to run. 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 think it may be a bit presumptuous to call cleanup wasteful. Proper cleanup is inefficient in in some cases, but execution time is only one metric. It may not be an important metric, either. Proper cleanup is necessary in other cases, like performing security testing and evaluation. Memory checkers like Asan and Valgrind can't differentiate between the "good" memory leaks and the "bad" ones. The good memory leaks can mask out the bad memory leaks. Bad memory leaks are never identified and fixed because they are assumed to be good memory leaks. The good memory leaks can cause this module and other modules to fail their testing. This one is important because the problem has escaped the module's boundary. When I am giving the choice between the program using extra 1000 cpu cycles to properly free memory or spending two hours of my time identifying fixing the memory leaks, then I choose the 1000 cpu cycles. Scale it up in an economic model: the problem can be fixed by the developer in one place at the cost of 1 hour and 1000 cpu cycles. Or, thousands of developers can fix it it multiple times at the cost of thousands of man hours. The economics don't work out. Or, view it as a code quality issue. Some organizations have governance that requires clean modules. Here, the organization selects their own criteria. This gives rise to two paths: an organization drops their standards to the lower GNU's standards. Or the module is brought up to conformance to meet the organization's higher standards. > > > We can only have subset of the bugs that everyone else has. I cannot > > > image > > > a situation where initialization of otherwise uninitialized scalar > > > variable > > > could introduce a new bug. > > > > I can. Perhaps the uninitialized variable has garbage in it that is > > typically nonzero, and a later bug in the program is triggered only by a > > rare combination of factors, one of which is that the variable must be > > zero. > > > > Of course there's no such bug in coreutils - but there's no bug of the > > flavor that you're imagining either. The point is that there's no proof > > that your bugs are a subset of everyone else's in this area. > > This part I do not understand. To put it simple, there are two cases: > > (1) The variable is always initialized before it is read. In this case the > explicit initialization is harmless. In some cases, optimizer drops the > redundant assignment anyway. If not, it is kept without having any impact > on the observable behavior of the program. > > (2) The variable is somewhere read before it is initialized. In this case > behavior of the original program is undefined. The explicit initialization > makes the behavior at least defined (even though not necessarily matching > author's expectations). I've always been a fan of (1), initialize everything. Let the optimizer decide if the initialization is unneeded. If deemed unneeded, the optimizer can forgo the store. If you initialize everything as a matter of policy, then (1) there is no doubt whether a variable is initialized, (2) it does not produce false positives, (3) it does not waste other people's time, and (4) it does not ask others to lower their standards (instead, the module conforms to other organization's higher standards). Jeff
