**Subject:** Re: humanize_number again

**To:** Alan Barrett *<apb@cequrux.com>*

**From:** Tomas Svensson *<tsn@gbdev.net>*

**List:** tech-userlevel

**Date:** 02/04/2002 15:38:55
>> Here is a modified version of humanize_number(9) that I think should
>> be sufficient for my df(1)/du(1) humanization needs. Differences
>> from the kernel version are:
>> [...]
>> - three flags can be used : HN_DECIMAL tells it to use one decimal
>> for numbers less than 10, HN_NOSPACE removes the space between
>> the number and the prefix and HN_B will use the prefix "B" for
>> numbers that would normally not have a prefix (bytes less than
>> 1000). Use 0 if no flags are used (not worth the trouble with
>> varargs?).
AB> It's difficult to imagine using a divisor other than 1000 or 1024, so
AB> the divisor arg could be replaced by more flags: HN_DIVISOR_1000 and
AB> HN_DIVISOR_1024.
Yes, but I think it would be better to assume 1024 and only have the
HN_DIVISOR_1000 flag.
AB> I don't much like the name HN_DECIMAL, because it seems to imply a
AB> choice of base (decimal versus hexadecimal or binary), whereas we want
AB> it to imply a choice of precision (number of decimal places). How about
AB> HN_DECPLACES_1 (allowing for a possible future HN_DECPLACES_2)?
The problem with more than one significant digit is that if you have
a string long enough to hold "5.62 MB" then it can also hold "5754 KB"
and the first result makes little sense, if any. I'm sure there is a
better name for HN_DECIMAL but I don't think HN_DECPLACES_1 is it.
-Tomas