Code review request for #6469160, #7088271 (original) (raw)

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/64691607088271/1/ <http://cr.openjdk.java.net/%7Ebpassani/64691607088271/1/> Bug #6469160: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6469160 Bug #7088271: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=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