Date: Sat, 15 Apr 2017 18:11:34 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ngie Cooper <ngie@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r316953 - head/sbin/savecore Message-ID: <20170415170730.T1682@besplex.bde.org> In-Reply-To: <201704150653.v3F6r7hJ081000@repo.freebsd.org> References: <201704150653.v3F6r7hJ081000@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Apr 2017, Ngie Cooper wrote:
> Log:
> Switch back to non-IEC units for 1024 bytes
>
> I was swayed a little too quickly when I saw the wiki page discussing
> kB vs KiB. Switch back as none of the code in base openly uses
> IEC units via humanize_number(3) (which was my next step), and there's
> a large degree of dislike with IEC vs more SI-like units.
> Modified: head/sbin/savecore/savecore.c
> ==============================================================================
> --- head/sbin/savecore/savecore.c Sat Apr 15 03:28:13 2017 (r316952)
> +++ head/sbin/savecore/savecore.c Sat Apr 15 06:53:07 2017 (r316953)
> @@ -322,7 +322,7 @@ check_space(const char *savedir, off_t d
> if (available < needed) {
> syslog(LOG_WARNING,
> "no dump: not enough free space on device (need at least "
> - "%jdKiB for dump; %jdKiB available; %jdKiB reserved)",
> + "%jdkB for dump; %jdkB available; %jdkB reserved)",
> (intmax_t)needed,
> (intmax_t)available + minfree,
> (intmax_t)minfree);
Thanks, but kB is almost as uncouth as KiB. Real K are in K or KB (except
for thermodynamicists, reak K are temperatures), and the K are real here.
It would have been reasonable to standardize kB for disk sellers'
kilobytes, but K was already taken for "Kelvin" in dehumanized (scientific)
units, and the same method was unavailable for disk seller's megabytes
since m was already taken for "milli". (Since millibytes don't exist,
mB for disk sellers' megabytes would work OK, but it needs the B suffix.)
"M" is also needed for decimal "million" in frequency and network
bandwidth descriptions. For network bandwidths the uncouth term is mb/sec
(millibits per second), or better yet, mbs (master of business selling or
millibit-seconds).
dehumanize^Wscientificize^Whumanize_number(3) does use k for 1000 and K
for 1024. This is actually documented.
dedehumanize^descientificize^Wexpand_number() doesn't understand this
or any of the uncouth formats produced by dehumanize_number(). It has
undocumented support for other lower case "prefixes" and only supports
upper case ones by converting to lower case. For k and K, this immediately
forgets the difference. dedehumanize_number() only supports powers of 2.
So when dehumanize_number() prints 1000 as 1k, dedehumanize_number()
misparses it the same as 1K and produces 1024 for both.
dedehumanize_number() has undocumented support for a [bB] suffix. It is
unclear if this suffix is for bytes or the common zeroth power of 2 and 10.
dedehumanize_number() has related parsing errors. It stops after the
first letter after digits. So it correctly parses 1iKB as garbage, but
it parses 1KiB as 1K and discards the the garbage after the K.
dehumanize_number() documents B a bit better, but says that it is a
"prefix" meaning "bytes". But since it means "bytes", it is a pure
suffix. The other "prefixes" are also suffixes in normal use. They
are suffixes to the number and only prefixes to the units, but the
units are normally left out. It is confusing to describe prefixes
to empty strings as being prefixes.
[bB] should also be avoided as a "prefix" since in dd it actually is
a prefix, meaning 512-blocks. dd has much better number parsers than
dedehumanize_number(), with less than 100 known bugs (counting duplicated
bugs separately). It supports almost any number of prefixes with
any values as multipliers. E.g., bs=1 iseek='1024*1000*1000*1000'
seeks through a real K of disk sellers' GB. It even attempts to detect
overflow in the multiplications and shifts. To get near 100 bugs in it,
I count minor things like:
- no support for E (exa)
- 8 bugs for the 8 supported multiplier letters by accepting both uppor
and lower case as meaning powers of 2. Letters are in short supply
even for powers of 2. Backwards compatibilty prevents changing the
meaning of k to 1000. This was originally broken by only using lower
case letters. This wasn't unimproved until 2004 when upper case aliases
were added.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170415170730.T1682>