RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length
Roger Riggs
Roger.Riggs at Oracle.com
Thu Feb 11 15:23:19 UTC 2016
Hi Chris,
The change to preallocate the StringBuffer is fine.
But I have misgivings about not consuming the data from the stream and
returning the empty string
for out of range lengths. It will silently leave the input stream in an
unusable state.
I think it should throw an exception (StreamCorruptedException would be
appropriate)
if the size is negative or too large.
BTW, a UTF string can be up to three times the length of a Java string
due to the encoding.
So utflen should be allowed to be Integer.MAX_VALUE * 3 (in the absence
of some other implementation limitation).
Roger
On 2/10/2016 9:25 AM, Aleksey Shipilev wrote:
> On 10.02.2016 17:07, Chris Hegarty wrote:
>> Thanks Aleksey, your proposal is better. So the complete change is:
>>
>> diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java
>> b/src/java.base/share/classes/java/io/ObjectInputStream.java
>> --- a/src/java.base/share/classes/java/io/ObjectInputStream.java
>> +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java
>> @@ -3144,7 +3144,12 @@
>> * utflen bytes.
>> */
>> private String readUTFBody(long utflen) throws IOException {
>> - StringBuilder sbuf = new StringBuilder();
>> + if (utflen < 0 || utflen > Integer.MAX_VALUE)
>> + return "";
>> +
>> + // a reasonable initial capacity based on the UTF length
>> + int initialCapacity = Math.min((int)utflen, 16384);
>> + StringBuilder sbuf = new StringBuilder(initialCapacity);
>> if (!blkmode) {
>> end = pos = 0;
>> }
>
> +1
>
> -Aleksey
>
>
More information about the core-libs-dev
mailing list