This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Bytecode verifier
- From: Tom Tromey <tromey at redhat dot com>
- To: Cedric Berger <cedric at berger dot to>
- Cc: Andrew Haley <aph at redhat dot com>, java at gcc dot gnu dot org
- Date: 31 Mar 2004 16:57:17 -0700
- Subject: Re: Bytecode verifier
- References: <1079384474.1995.85.camel@localhost.localdomain><1079532074.29202.1033.camel@localhost.localdomain><87oeqv49qc.fsf@fleche.redhat.com><16472.41028.957290.280721@cuddles.cambridge.redhat.com><878yhz47lb.fsf@fleche.redhat.com> <40680799.2070806@berger.to>
- Reply-to: tromey at redhat dot com
>>>>> "Cedric" == Cedric Berger <cedric@berger.to> writes:
Cedric> I don't know how effective that would be, but that's pretty easy to
Cedric> create bad bytecode mechanically. For example, just just take correct
Cedric> bytecode, and then run it (uncompressed) through something like that
Cedric> (untested):
Nice idea.
Cedric> Then the resulting bugcode could be fed to both GCJ and Sun's
Cedric> verifier for comparaisons.
Unfortunately Sun's verifier and ours reject and accept different
code. The deal is, "invalid bytecode" is not perfectly well defined.
Instead, there are restrictions in the JVM Spec which are basically
incoherent. It doesn't look easy to write a verifier which behaves
the same as Sun's, particularly considering that theirs has changed
over time.
Tom