JDK-4868205 : InflaterInputStream.available() returns wrong value
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-05-22
  • Updated: 2004-09-01
  • Resolved: 2003-06-27
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.
Other
5.0 tigerFixed
Related Reports
Relates :  
Description

Name: auR10023			Date: 05/22/2003



Method java.util.zip.InflaterInputStream.available() returns 0 but 1
expected. The javadoc for this method says:

...
public int available()
              throws IOException

          Returns 0 after EOF has been reached, otherwise always return 1. 

          Programs should not count on this method to return the actual number of bytes that could be read without blocking.
          ...

Following test skips valid amount of bytes, so there should be no EOF.


Here is the example:

-------t.java---------
import java.util.zip.*;
import java.io.*;

public class t {
    private final static byte orig[] = {
        125, 28, 58, 101, 36, 5, 64, 55, 77, 68, 42,
        71, 84, 125, 15, 74, 104, 44, 49, 28, 22, 17,
        19, 68, 121, 123, 100, 75, 76, 120, 30, 54,
        64, 21, 36, 35, 54, 82, 65, 118, 82, 1, 68,
        19, 3, 72, 99, 72, 36, 61, 3, 87, 115, 104,
        21, 71, 77, 120, 21, 84, 110, 38, 39, 2, 14,
        91, 43, 127, 28, 91, 112, 73, 20, 30, 120,
        72, 43, 55, 102, 105, 57, 64, 58, 61, 96,
        126, 122, 52, 66, 111, 83, 57, 9, 45, 5, 47,
        117, 35, 51, 60 
    };
    private final static byte compressedOrig[] = {
        120, -100, -85, -107, -79, 74, 85, 97, 117,
        48, -9, 117, -47, 114, 15, -87, -27, -9, -54,
        -48, 49, -108, 17, 19, 20, 118, -87, -84, 78,
        -15, -10, -87, -112, 51, 115, 16, 85, 81, 54,
        11, 114, 44, 11, 98, 116, 17, 102, -10, 72,
        -10, 80, -79, 101, 14, 47, -50, 16, 117, -9,
        -83, 16, 13, -55, 83, 83, 103, -30, -117, -42,
        -82, -105, -119, 46, -16, 20, -111, -85, -16,
        -48, 54, 79, -53, -76, 116, -80, -78, 77, -88,
        -85, 50, 113, -54, 15, -74, -28, -44, 101,
        -43, 47, 85, 54, -74, 1, 0, -34, -35, 25, 7 
    };

    public static void main(String [] args) {
        boolean passed = false;
        byte[] buf = new byte[orig.length];
        InputStream bis = new ByteArrayInputStream(compressedOrig);
        InflaterInputStream iis = new InflaterInputStream(bis);
        try {
            iis.skip(orig.length);
            if (iis.available() == 1) {
                passed = true;
            }
            iis.close();
        } catch (IOException e) {
            passed = false;
            System.out.println("Unexpected " + e + " thrown.");
        }
        System.out.println( passed);
    }
}


Here is the result
#java -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b06)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b06, mixed mode)

#java t
false

Following jck test fail due to this bug:

api/java_util/zip/InflaterInputStream/index.html#Misc[InflaterInputStream0005]

======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b10 VERIFIED IN: tiger-b63
13-09-2004

EVALUATION This is due to the fix for 4795134. That fix was based upon an interpretation of the spec that maintains that "EOF has been reached" occurs when sitting right before reading EOF but have not yet read EOF. However, in revisiting this code it has been discovered that the algorithm used to detect this case was flawed anyway. So, I will revert the behavior. ###@###.### 2003-05-23
23-05-2003