Date: Sat, 7 Oct 2006 02:40:28 GMT From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/102694: df(1) can forget to print the unit with -h Message-ID: <200610070240.k972eSmT088967@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/102694; it has been noted by GNATS.
From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org>
To: bug-followup@FreeBSD.org
Cc: ceri@FreeBSD.org
Subject: Re: bin/102694: df(1) can forget to print the unit with -h
Date: Fri, 6 Oct 2006 23:36:34 -0300
> Not sure if this is df(1) or libutil's humanize_number(3)
> to be honest.
I was looking at it and was able to reproduce it and found what's going on.
What happens is that, for numbers close to the next scale (1000<= x <1024),
the scaled number is big for the 6-char buffer, which in fact is told be be
6-1 bytes. From the source:
humanize_number(buf, sizeof(buf) - (bytes < 0 ? 0 : 1),
bytes, "", HN_AUTOSCALE, flags);
That "sizeof(buf) - (bytes < 0 ? 0 : 1)" causes humanize_number to think that
the buffer has only 5 chars, thus producing:
[ ][1][0][0][0][\0]
If one remove that restriction, the unit comes back:
[1][0][0][0][M][\0]
The drawback is that it no longer scales "humanly" for numbers >= 1024, going
up to 9999 (ugly).
I spent a good time trying to figure out a clean and effective solution, but
the best I got was to not use humanize_number, and scale the number locally.
If that is good enough, I can clean up my code and send a patch.
Regards.
--
Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}>
Powered by FreeBSD
"Left to themselves, things tend to go from bad to worse."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610070240.k972eSmT088967>