[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Meyering
Subject: Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Date: Thu, 04 Sep 2008 09:32:25 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]