Patch to fix BufferedInputStream.skip and bug 4254082

[Dave Bristor]

Hi Pascal,

Pascal S. de Kloe wrote:
> Hello Christopher,
> 
> Thank you for this information. :)
> 
> Would you happen to know if somebody even tried to make a better 
> available() for ZipInputStream?
> For instance, the manual of gzip(1) notes that the compressed data can 
> only be a 5B larger per 32KB block than the original in the worst case 
> scenario.

While such a change might be desirable, it would be an incompatible change, as 
ZipInputStream.available() has been defined to return 0 or 1 since it was 
first introduced in 1998 (ditto for base class 
InflaterInputStream.available()).  By now it is possible that some code is 
depending on this behavior.  Sad but true, and so we are loathe to change it.

Thanks,
	Dave

> 
> The current BufferedInputStream is known not to work in various 
> situations and with various other streams. I'd say that the correctness 
> of operation is more important than performance problems. Besides, 
> buffering a ZIP stream is weird, isn't it? Is documenting this 
> limitation a option?
> 
> For the specific patch posted earlier that day skip() should be fine but 
> read() and read(byte[], int, int) will be affected.
> 
> 
> On Wednesday 11 July 2007 00:35:09 you wrote:
> 
>>Hi Pascal, Bill, et al,
>>
>>I was responsible for integrating the contributed fix for 6192696.
>>The problem with it was that it relied on a 'good' implementation of
>>the available method. By 'good' I mean that it actually returns the
>>amount of data that can be read without blocking, and not simply 1.
>>ZipInputStream.available simply returns 1 (if there is any data
>>available) as it is difficult to determine the amount of available
>>data when dynamically uncompressing a data stream.
>>
>>Now, using available to try and fill as much of BufferedInputStream's
>>internal buffer without blocking may result in reading only 1 byte at
>>a time from the underlying stream, creating a performance
>>degradation. See 6409506 and 6411870.
>>
>>I'm not sure what exactly is being proposed here, but if available is
>>going to be used to optimize the amount of data actually skipped, be
>>aware of the limitation of ZipInputStream.available and other 'bad'
>>available implementations.
>>
>>-Chris.
>>
>>Pascal S. de Kloe wrote:
>>
>>>Hello Martin,
>>>
>>>
>>>>6192696: BufferedInputStream.read(byte[], int, int) can block if
>>>>the entire buffer can't be filled
>>>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696
>>>
>>>The problem is fill(). It doesn't check available(). The patch on
>>>this mailing list is supposed to fix that too.
> 
> 
>