RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..)

[Alan Bateman]

On 04/03/2022 10:04, Volker Simonis wrote:
> :
>
> 1. Relax the specification of `InflaterInputStream::read(..)` and
> specifically note in the API documentation that a call to
> `InflaterInputStream::read(byte[] b, int off, int len)` may write more
> than *k* characters into `b` where *k* is the returned number of
> inflated bytes. Notice that there's a precedence for this approach in
> `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden
> method of InputStream, returns -1 instead of zero if the end of the
> stream has been reached and len==0*".
>
On the surface this is probably okay. It wouldn't really be relaxing the 
specification, rather than it would say for a return value n, the bytes 
in b[n] to b[len-1] are undefined as the read operate may have clobbered 
their original values. The risk is that it becomes a performance "trick" 
to provide a larger buffer. That said, I think the main thing we need to 
satisfy ourselves on is security. One part of that is whether anything 
can be gleaned by reading from the byte array during or after an 
inflate. The other part is how the implementation behaves when there is 
a tampering of the array contents during an inflate.

-Alan