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

[enh]

On Sun, Aug 23, 2015 at 6:20 PM, Rob Landley <rob at landley.net> wrote:
> 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:
>>> 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.
>
> It looks like the double version can say "1023M", which isn't right
> either. Yes, ubuntu can too:
>
> $ truncate blah -s $((1023*1024))
> $ du -h --apparent-size blah
> 1023K   blah
>
> You're already saying you don't want to copy them getting the rounding
> wrong, but this is the wrong number of _digits_. The base 10 one is 3
> digits max, either via "9.8" or "321". This one can go to 4 digits. I
> thought the reason for the "double" was to take care of that, but
> apparently not?

no, i was just trying to get the rounding "obviously right".

the behavior matches what google usually does, and matched the
coreutils outputs in my ubuntu box's /, /tmp, and a checked-out toybox
repository. i've not seen the coreutils code, but i do know the BSD
code has a bunch of extra heuristics.

> I was halfway through doing an if (CFG_TOYBOX_FLOAT) one with the double
> and an else case with the long long, but I _think_ what we need to do is
> test against 999 each time and if we overshoot slightly it should round
> up as 1.0 of the next unit? So decimal test always, but binary divide
> where appropriate.
>
> The ubuntu behavior is...
>
> $ truncate blah -s $((3000*1024))
> $ du -h --apparent-size blah
> 3.0M    blah
>
> That got rounded up (3000 < 3*1024) so 1001KB being 1.0MB is also
> legitimately something you can round up? I think?
>
> /me wists for a specification. Oh well. I hate when I have to guess at
> what the right behavior _is_...

yeah, i was actually trying to avoid ending up with all the heuristics
the BSD implementation has.

the BSD man page says:

     If the formatted number (including suffix) would be too long to fit into
     buf, then divide number by 1024 until it will.
...
     The len argument must be at least 4 plus the length of suffix, in order
     to ensure a useful result is generated into buf.

so it certainly seems they follow the "no more than three digits/two
digits plus '.'" rule.

>> (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...
>
> I added a test command to toys/examples and a very simple one to tests/
> but I need the *.test file waaaay fluffed out. :)
>
> Rob



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

 1440447032.0