>> 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