Bug ID: JDK-8253459 Formatter treats index, width and precision > Integer.MAX

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 16
16 b26Fixed

A DESCRIPTION OF THE PROBLEM :
The source code of java.util.Formatter has 3 `assert(false)` statements:
- When the argument index cannot be parsed as int
- When the width cannot be parsed as int
- When the precision cannot be parsed as int

All of them can be triggered when the arguments are > Integer.MAX_VALUE. Expected would be that an exception is thrown.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected exceptions to be thrown

---------- BEGIN SOURCE ----------
String.format("%2147483648s", 1) // Acts like no explicit width
String.format("%s %2147483648$s", 1) // Acts like "Relative indexing"
String.format("%.2147483648f", 1.0) // Acts like no explicit precision
---------- END SOURCE ----------

The results from the submitter: I guess the commit solves JDK-8253459, so feel free to consider this resolved.
15-01-2021
Requested the submitter verify the fix with latest version of JDK 16.
13-01-2021
Changeset: 080c707a Author: Ian Graves <igraves@openjdk.org> Committer: Stuart Marks <smarks@openjdk.org> Date: 2020-11-19 20:20:55 +0000 URL: https://github.com/openjdk/jdk/commit/080c707a
19-11-2020
Noting that the docs for java.util.Formatter note that argument index values are limited to the maximum array index. This is currently Integer.MAX_VALUE. What's undefined is what occurs if a larger value is supplied.
02-10-2020
The situation here appears to be that, indeed, these situations do progress through the asserts mentioned in the bug. These asserts, however, are system asserts that will only trip if the vm is run with system asserts enabled `-esa`. Doing so causes these to throw exceptions. Since they are not thrown, what we're observing is internal Formatter initial field values falling through and coming back to the user to produced the behavior noted in this bug. I think the most straightforward fix here is to set the maximum size of a width, precision, or argument index to Integer.MAX_VALUE. The documentation does not define an upper bound for these numbers.
30-09-2020
The observations on Windows 10: JDK 8: Failed, expected exceptions not thrown JDK 11: Failed JDK 14: Failed JDK 15: Failed
22-09-2020
More explanation of the test code from the submitter: The Integer.MAX_VALUE is 2147483647. The test code uses 2147483647 + 1 = 2147483648 which cannot be represented as `int`.
22-09-2020
Requested more details of Integer.MAX_VALUE which triggers the problems.
21-09-2020

CSR :	JDK-8253875 - Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly
Relates :	JDK-8253393 - Formatter does not throw exception for 0 as argument index