Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)

[Jim Meyering]

Bruno Haible <address@hidden> 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.