Date: Tue, 25 Dec 2012 07:20:37 -1000 From: Clifton Royston <cliftonr@volcano.org> To: freebsd-hackers@freebsd.org Cc: John-Mark Gurney <jmg@funkthat.com> Subject: Re: looking for someone to fix humanize_number (test cases included) Message-ID: <20121225172037.GA56225@volcano.org> In-Reply-To: <mailman.15.1356350401.35494.freebsd-hackers@freebsd.org> References: <mailman.15.1356350401.35494.freebsd-hackers@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 24, 2012 at 12:00:01PM +0000, freebsd-hackers-request@freebsd.org wrote: > Date: Sun, 23 Dec 2012 00:32:20 -0800 > From: John-Mark Gurney <jmg@funkthat.com> > To: hackers@FreeBSD.org > Subject: looking for someone to fix humanize_number (test cases > included) > Message-ID: <20121223083220.GL1563@funkthat.com> > Content-Type: text/plain; charset=us-ascii > > I'm looking for a person who is interested in fixing up humanize_number. > > The other day I copied some data from a 7.2-R box to a 9.1-stable box > and did a du -shc and a du-skc to check the results... I noticed the -h > run dropped from 11M to 10M, which I thought was weird... Then I looked > at the results from the -k run, but the new machine had a larger result > (I copied from UFS to ZFS)... It turns out that humanize_number was > broken when doing rounding... No longer does humanize_number round up > at .5 or more of the prefix.. > > So I decided to write a test program to test the output, and now I'm even > more surprised by the output... Neither 7.2-R nor 10-current give what > I expect are the correct results... > > Feel free to take a look at the test program posted to: > http://people.freebsd.org/~jmg/humanize_numbers/ > > The .c contains what I think the output should be. I'm testing on 7.3R (yes, I know, I know, should be on 8 or 9) and see similar results as to rounding problems; see below on the others. > So far the bugs I know of: > 1) rounding is incorrect (started this whole search) > 2) buffer calculation is incorrect in some cases, index 11 should fit > but doesn't > 3) some cases zero is returned though it isn't zero, more like 0T for 512 G > (indexes 16, 17, 22, 23) I think these last are caused by integer wraparound and truncation in the integer constant calculations of your test program, once you get beyond 1G. Even though it's an anachronism in these days of 3TB disks and 8GB RAM in laptops, int is still 32 bits in most C implementations, giving a maximum range of +/- 2G, and constant calculations are done with int by default. Your point 1 and 4 seem correct, at first glance. I've tweaked the test slightly to correct those cases - trailing L doesn't do it, you must also prefix the constant value with (int64_t) - and it fixes the dimensionless 0s for 16, 17, 22, and 23, and the buffer error for 11 (caused because it probably comes out with some really weird value after truncation.) There's another brain-blip bug which took me a couple minutes of staring at - your test skips over "peta-" and expects "exa-" (E) to come after "tera-". Fixing that by replacing "1 E" and "2 E" with "1 P" and "2 P" corrects a couple more errors. I'm left with index 1-11 all showing one less than expected ("0 K" for "1 K", and so on to "1 T" for "2 T"), and 25 and 27 showing the same problem - so at least it's down to just the rounding problem. There's actually another problem implicit in the results from the rounding problem - I think it should never yield "0 M" instead of "512 K"; for that matter, I would think anything up to "999 K" (divisor 1000) or "1023 K" (divisor 1024) should be represented with the smaller unit, not as "1 M". > 4) man page is missing required sys/types.h include > > I'll work to get the code into the tree once we get it in a good state. No promises as I'm chronically oversubscribed but it's intrigued me and I'll take a look. > Please cc me as I'm not subscribed to -hackers. Done. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@volcano.org President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121225172037.GA56225>