Code review request for #6469160, #7088271

[Joe Darcy]

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.