Re: java/6462: jc1 "Cannot allocate xxx bytes after allocating yyyy bytes" message

[Tom Tromey <tromey@redhat.com>]

The following reply was made to PR java/6462; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Christl Timon <me@christltimon.de>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/6462: jc1 "Cannot allocate xxx bytes after allocating yyyy bytes" message
Date: 29 Apr 2002 15:36:06 -0600

 >>>>> ">" == Christl Timon <me@christltimon.de> writes:
 
 I've CC'd gcc-gnats so that this will be logged in the PR.
 
 >> Note especially #2: The source line is
 
 >> zipf-> central_directory=ALLOC(zipf->dir_size+1);
 
 >> For a certain jar file in my $CLASSPATH (retroguard.jar, a bytecode
 >> optimizer and obfuscator) the value of zipf->dir_size is unusally large.
 >> Seems that the makers of retroguard have corrupted the jarfile with
 >> their own product. When I remove this jar file from my $CLASSPATH it works.
 
 Thanks for analyzing this.
 
 We definitely can't support cases where a jar file is intentionally
 corrupted like this.  jar files must conform to the spec.
 
 Perhaps we could change this xmalloc() to an ordinary malloc() and
 print a nicer error message before dying.  That's pretty low priority
 for me, but if you want to write a patch that would be helpful.
 
 Tom