From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1078 invoked by alias); 22 Sep 2004 16:02:10 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1049 invoked by uid 48); 22 Sep 2004 16:02:09 -0000 Date: Wed, 22 Sep 2004 16:02:00 -0000 Message-ID: <20040922160209.1048.qmail@sourceware.org> From: "sorabain at hotmail dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040305092750.14446.gcj@stuellenberg.de> References: <20040305092750.14446.gcj@stuellenberg.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/14446] GZIPInputStream: corrupted gzip file - crc mismatch X-Bugzilla-Reason: CC X-SW-Source: 2004-09/txt/msg02572.txt.bz2 List-Id: ------- Additional Comments From sorabain at hotmail dot com 2004-09-22 16:02 ------- We had the same problem, and i found the cause: java.util.zip.GZIPInputStream.java in libjava has a method called read4() that reads in 4 bytes and returns them as an int (java integers are signed). this is compared to CRC32.getValue(), which returns a long. The int is promoted to a long for the comparison, but if the most significant (sign) bit is set this will be a negative number, whereas the long with the same original low 32-bits is positive. The comparison fails. To fix it i just changed the return type of read4() to be a long in-line with the type of CRC32.getValue() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14446