Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Other opinions welcome. > > I mostly agree with Eric here: gnulib's substitute does not guarantee > that values stored in a 'bool' are either 0 or 1, therefore the code that > creates 'bool' values must guarantee it. > >> The question is how best to *maintain* the precondition in >> the face of future development. > > By code inspection. We have no compiler warning for this kind of thing. > >>> Some of the changes (& => &&) are unconditional improvements, imho. > > I disagree. The & => && change inserts a conditional branch into the control > flow, with the potential to save a single memory access. I count ca. 2 CPU > cycles for a memory access and ca. 8 CPU cycles for a conditional jump, > therefore I would say that the change slows down the program a bit.
Surely you are not quibbling about a few extra cycles in the run-time of *df*. This is no hot code path. I suppose you're merely raising a theoretical counterpoint to my absolute statement. The benefit of using "&&" over "&" in those cases is precisely to obviate that tedious code inspection. That benefit far outweighs the minuscule (and probably not measurable) cost of a few extra CPU cycles in df.
