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

Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable



On Thu, 9 Aug 2012 13:53:30 +0200
Christian PERRIER <bubulle@debian.org> wrote:

> I'd like to get other D-I people advice about including these changes
> *now* as thereis always a risk of regressions which, at this point of
> the release, we would like to avoid.

That's an important consideration. I offer the following test scripts as
evidence of non-regression.

The h-to-l.sh and l-to-h.sh scripts should be run in busybox, once with
the old definitions of human2longint() and longint2human(), and once
with the new definitions, and the output saved to file.

The old and new versions of human2longint() produce output that is
byte-for-byte identical.

The new versions of longint2human() produces output that is different
from the old in the following respects, as previously advertised:

- if the chosen unit is bytes, then decimal fractions are not printed

- otherwise, two decimal places are printed

- values such as 999999 are rounded up to "1.00 MB"

The third script, round.sh, when applied to the new version output,
accounts for the first two causes of difference, leaving the third:

    $ ./round.sh <l-to-h.new | diff l-to-h.old -

These tests must obviously be run in decimal mode, since the reason for
the patch is that the old code does not operate with binary unit values.

I would be interested to hear suggestions as to what sort of tests of
binary mode operation would be considered sufficient for the patch to be
accepted.


-- Ian Bruce

Attachment: h-to-l.sh
Description: application/shellscript

Attachment: l-to-h.sh
Description: application/shellscript

Attachment: round.sh
Description: application/shellscript


Reply to: