svn commit: r316938 - head/sbin/savecore

Ngie Cooper (yaneurabeya) yaneurabeya at gmail.com
Sat Apr 15 02:41:01 UTC 2017


> On Apr 14, 2017, at 18:49, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
> 
>> On Friday, April 14, 2017 07:41:48 PM Ngie Cooper wrote:
>>> Author: ngie
>>> Date: Fri Apr 14 19:41:48 2017
>>> New Revision: 316938
>>> URL: https://svnweb.freebsd.org/changeset/base/316938
>>> 
>>> Log:
>>>  savecore: fix space calculation with respect to `minfree` in check_space(..)
>>> 
>>>  - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
>>>    representable data to INT_MAX. Check the values received from
>>>    strtoll(3), trimming trailing whitespace off the end to maintain
>>>    POLA.
>>>  - Use `KiB` instead of `kB` when describing free space, total space,
>>>    etc. I am now fully aware of `KiB` being the IEC standard for 1024
>>>    bytes and `kB` being the IEC standard for 1000 bytes.
>> 
>> I will just rant lightly that no one actually uses this in the real world.
>> 
>> Good lucking finding a "16 GiB" DIMM on crucial.com or a 4Kin drive.  A
>> kilobyte is a power of 2.  The End.
>> 
>> (Next up we'll have to rename 4k displays to
>> 4k<insert arbitrary and unrelated letter here>)
> 
> Do we use KiB, MiB, GiB,... any place else in the system?  I cant think of
> a place we do this, so please, lets not start doing this here?

humanize_number(3) from libutil uses IEC units.

> Yes, these are newer standards, perhaps some day we should make a global
> switch to them, but lets not start mixing and matching things.

I understand and agree. I’m not 100% sold on that one way or another, but since I was going to redo the number representation in save core with humanize_number(3), because reading `<really-long-int>KiB` is not ideal usability wise, and I don’t want to reinvent the wheel normalizing numbers and printing out the unit.

Perhaps there should be a flag baked into humanize_number, etc for parsing IEC vs non-IEC unit values?

Thanks for the input :)!
-Ngie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170414/c8255464/attachment.sig>


More information about the svn-src-head mailing list