> On Apr 14, 2017, at 18:49, Rodney W. Grimes <free...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
