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

[Rob Landley]

On 08/17/2015 03:38 PM, enh wrote:
> 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.

More that it was added well into the process and not everything got
converted over. (One of my proposed aboriginal test environments has no
floating point, so that's a test case once I've got it working, but
that's queued up after the nommu support.)

>> 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.

Can the long long not round properly?

> (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 :-) )

Alas I swing between almost neurotic levels of testing and "I need to do
a testing pass before the release, no time for it now"...

(I have a whole "properly fill in the test suite" pass scheduled, but
it's about as big as implementing vi, and I've been holding off so I
don't have to do it multiple times. In theory I could declare individual
commands finished and do their tests (and I've done a few), but I keep
thinking I'm finished with stuff like ls and being wrong...)

Todo list, runneth over. This is indeed important, as is documentation,
as is clearing out pending, as is a regular release schedule...

>> (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...

Usually I try to find a tool that exposes the library functionality, but
there are some cases I can't easily do that for, yes.

Possibly I need to add some more commands under toys/example just so I
can have the test suite call them? Hmmm...

Rob

 1439871875.0