On Mon, 23 Aug 2010, [utf-8] Dag-Erling Sm??rgrav wrote:
Dimitry Andric <dimi...@andric.com> writes:
Dag-Erling Sm??rgrav <d...@des.no> writes:
Bruce Cran <br...@cran.org.uk> writes:
Somewhat related, there are overflow bugs in humanize_number - for
example df(1) fails to display space from a 100PB filesystem
correctly.
Patch? :)
Attached. This makes humanize_number() work properly for all possible
int64_t values.
That's awesome! Any way I can convince you to fix expand_number() as
well? I got a detailed explanation of what's wrong with it (both before
and after my commits) from bde@ (cc:ed) in private correspondence; I can
forward it to you if he doesn't mind.
OK.
I think the final point was that it should go back to supporting signed
numbers (only), and that means int64_t ones until scientificize^dehumanize^W
humanize_number() is fixed to support intmax_t ones.
Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
