RFR 8139206: Add InputStream readNBytes(int len)
Adam Petcher
adam.petcher at oracle.com
Mon Jan 22 15:56:12 UTC 2018
The spec of the new method doesn't give me enough information to
determine whether it is safe to call it when the value of the length
argument is much larger than the number of bytes I expect to actually
read. This use case comes up frequently in security libraries, because
we have to handle length values that were chosen by an attacker. Would
it be possible to add a sentence or two to the spec to clarify this
situation?
Possible wording, if this method can be called with large length values:
"The total amount of memory allocated by this method is proportional to
the number of bytes read from the stream. Therefore, the method may be
safely called with very large values of {@code len}.
Possible wording, otherwise:
"The total amount of memory allocated by this method may be proportional
to the value of {@code len}. Therefore, calling this method with very
large values of {@code len} is not recommended."
On 1/17/2018 11:24 AM, Brian Burkhalter wrote:
> The proposed change has been modified to replace the two methods
>
> byte[] InputStream.readAllBytes(int) // reads at most ‘len’ bytes
> byte[] InputStream.readNBytes(int) // reads exactly ‘len’ bytes or throws IOException
>
> with a single method
>
> byte[] InputStream.readNBytes(int) // reads at most ‘len’ bytes
>
> A negative value of ‘len’ will now cause an IllegalArgumentException instead of an IndexOutOfBoundsException. Also some verbiage has been improved.
>
> http://cr.openjdk.java.net/~bpb/8139206/webrev.01/
>
> Thanks,
>
> Brian
>
> On Jan 16, 2018, at 11:17 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8139206
>> http://cr.openjdk.java.net/~bpb/8139206/webrev.00/
>>
>> This change would add a new method “byte[] InputStream.readNBytes(int len)” which would read up to at most ‘len’ bytes from the stream and return them in an internally allocated array.
More information about the core-libs-dev
mailing list