Code review request for #6469160, #7088271
Joe Darcy
joe.darcy at oracle.com
Fri Jan 20 18:30:42 UTC 2012
As a general comment, I find a seven-digit bug id in isolation
extremely uninformative in terms of letting me know whether or not an
issue is of interest to me. For the messages I send to the list, I
always try to include the synopsis of the bugs in question in at least
one of the subject line and the body of the message.
-Joe
On 1/20/2012 10:19 AM, Brandon Passanisi wrote:
> Resending again...
>
> Hello core-libs. I was wondering of somebody could be please review
> the following fix for #6469160 and #7088271. The changes in the
> webrev fix both bugs. Information is below:
>
> Webrev URL: http://cr.openjdk.java.net/~bpassani/6469160_7088271/1/
> <http://cr.openjdk.java.net/%7Ebpassani/6469160_7088271/1/>
> Bug #6469160:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
> Bug #7088271:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088271
>
> Both bugs uncover the current behavior where using a 0 or 1 precision
> value with a float zero causes an ArrayIndexOutOfBoundsException. The
> current code in FormattedFloatingDecimal.java interprets the float
> zero as "0.0" in the case where precision is 0 or 1 and returns the
> length of it's characters as 3. Later in Formatter.addZeros(), the
> character array "0.0" is passed in, but a new array of only 1
> character is allocated. When an System.arraycopy() is performed, the
> ArrayIndexOutOfBoundsException occurs. In fact, when run with "-esa"
> an AssertionError occurs at "assert (outPrec <= prec);" on line 3393
> of Formatter.java. The fix is for FormatedFloatingDecimal.java to
> interpret the float zero as a single "0" because of the precision
> being set to 0 or 1.
>
> Since java has been throwing exceptions in these cases, I consulted
> with the output of C's printf to make sure that the outputted strings
> are the same. I updated the Formatter's Basic-X template of tests
> with a little over 20 test format strings that were causing exceptions
> without the change and the output of each is compared with the output
> from C's printf with the same format string. And, I ran all of the
> Basic-X tests to make sure there weren't any regressions in behavior.
>
> Thanks.
More information about the core-libs-dev
mailing list