> On Apr 14, 2017, at 20:05, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> > wrote: > >>> >>> 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. > > And how many things bother to use this library function? Do the > ones that do call it produce the traditional output that has been > around for 40 years? > >>> 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 > ^^^ > I hope we are not already reading KiB anyplace….
I meant it’s a lot harder for humans to read `<really-long-int>KiB` instead of `<appropriately-scaled-int><appropriate-byte-unit>`. >> 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? > > I dont think it parses anything, but as far as producing strings from values > it already has an IEC flag: HN_IEC_PREFIXES, please lets not use this flag, > and if we are using it anyplace lets see if we can remove that use. I don’t see it used anywhere in the tree, based on a quick grep. > Also be careful, this function only accepts signed int 64, which means > we are not gona be able to use this in all places that probably need > this, so perhaps a larger can of paint for a bigger bike shead is needed? I don’t necessarily follow the above statement 100%. Are you warning against mass-conversion to libutil (if so, I agree… this was just a case where it really helps readability in savecore(8))? Thanks! -Ngie
signature.asc
Description: Message signed with OpenPGP using GPGMail