[Toybox] [PATCH] Add support for 1024 as well as 1000 to human_readable.

[enh]

On Mon, Aug 17, 2015 at 12:02 PM, Rob Landley <rob at landley.net> wrote:
> On 08/15/2015 05:20 PM, enh wrote:
>> Add support for 1024 as well as 1000 to human_readable.
>>
>> This fixes the issue found with du, and paves the way for ls -lh (in a
>> separate patch). In manual testing this produces similar results to
>> coreutils, but better in some cases, presumably due to bad rounding in
>> coreutils. (toybox's 5675-byte main.c, for example, should be rounded
>> to 5.5Ki, not the 5.6 that coreutils reports.)
>>
>> I've preserved support for SI multiples of 1000, but haven't bothered
>> to work out whether dd actually wants that. "It's in pending for a
>> reason", after all.
>>
>> diff --git a/lib/lib.c b/lib/lib.c
>> index c16cffe..2f80be3 100644
>> --- a/lib/lib.c
>> +++ b/lib/lib.c
>> @@ -866,23 +866,22 @@ void names_to_pid(char **names, int
>> (*callback)(pid_t pid, char *name))
>>    closedir(dp);
>>  }
>>
>> -// display first few digits of number with power of two units, except we're
>> -// actually just counting decimal digits and showing mil/bil/trillions.
>>  int human_readable(char *buf, unsigned long long num, int style)
>>  {
>> -  int end, len;
>> +  double amount = num;
>> +  const char *unit = (style&HR_SI) ? " kMGTPE" : " KMGTPE";
>> +  int divisor = (style&HR_SI) ? 1000 : 1024;
>> +  int end;
>
> config TOYBOX_FLOAT
>         bool "Floating point support"
>         default y
>         help
>           Include floating point support infrastructure and commands that
>           require it.
>
> Not relevant to android, but I've been trying to let toybox work on
> systems without even emulated floating point support. (If I'm trying
> to displace busybox, leaving it obvious niches that busybox does
> but toybox doesn't do is unfair to those niches.)

i did see TOYBOX_FLOAT but not all the existing floating point code is
guarded by it so assumed it was bitrotting to death.

> I take a stab at making it work with long long, and if it's nontrivial
> I'll bite the bullet and merge the double version.

it would be nice if you could keep the double versions for builds that
allow floating point. i suspect that coreutils isn't using floating
point under the hood, because some of its rounding seems wrong. it
would be sad to pessimize toybox on real hardware to support such a
minority use case.

(even though they're easy enough to find, i didn't list examples above
because i didn't want to encourage you to break things :-) )

> (What would be really
> nice would be test cases, but I'll see what I can come up with.)

this is why you need unit tests for the library rather than relying on
testing the final tools...

> It's too bad du --apparent-size hasn't got a short option or I'd add
> that so I could hijack du.test to test human_readable() in various
> rounding conditions via truncate -s. (Might still anyway, but that's
> a really stupid longopt name that gnu came up with there...)
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1439843893.0