bug#17505: Interface inconsistency, use of intelligent defaults.

[Ruediger Meier]

On Friday 16 May 2014, Pádraig Brady wrote:
> On 05/16/2014 02:24 AM, Linda Walsh wrote:
> > On programs that allow input and output by specifying
> > computer-base2 powers of K/M/G  OR decimal based powers of 10,
> >
> > If the input units are specified in in powers of 2 then the output
> > should be given in the same units.
> >
> > Example:
> >
> > dd if=/dev/zero of=/dev/null bs=256M count=2
> > ... So 512MB, total -... but what do I see:
> > 536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s
> >
> > Clearly 256*2 != 537.
> >
> > At the very least this violates the design principle of 'least
> > surprise' and/or 'least astonishment'.
>
> I agree that the units representation is unfortunate,
> but an accident of history.
> POSIX species 'k' and 'b' to mean 1024 and 512 respectively.
> Standards wise 'k' should really mean 1000 and 'K' 1024.
> Then extending from that we now have (which we can't change for
> compat reasons):
>
>   k=K=kiB=KiB=1024
>   kb=KB=1000
>   M=MiB=1024^2
>   MB=1000^2
>   ...
>
> However when _outputting) the stats line we could use the
> least ambiguous and most standard unit, which would be the IEC unit.
> The attached patch changes the output to:
>
>   $ dd if=/dev/zero of=/dev/null bs=256M count=2
>   2+0 records in
>   2+0 records out
>   536870912 bytes (512 MiB) copied, 0.152887 s, 3.3 GiB/s

Thanks!
What about just "512 M" which looks IMO better, is a valid input unit 
and is explained in the man page.


cu,
Rudi