You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-dev@jakarta.apache.org by en...@apache.org on 2002/03/09 23:30:15 UTC
cvs commit: jakarta-bcel/src/java/org/apache/bcel/verifier/structurals InstConstraintVisitor.java
enver 02/03/09 14:30:15
Modified: . TODO.JustIce
src/java/org/apache/bcel/verifier/structurals
InstConstraintVisitor.java
Log:
I put some checks back in which I commented out while there was a problem with BCEL
check for assignment compatibility (which was rooted someplace else).
However, this could cause JustIce to reject code that's not rejected by traditional
verifiers.
I got a bug report today from a person who found a class that was rejected by a traditional
verifier but not by JustIce - which is even more annoying. So I switched. See TODO.JustIce .
Revision Changes Path
1.3 +10 -2 jakarta-bcel/TODO.JustIce
Index: TODO.JustIce
===================================================================
RCS file: /home/cvs/jakarta-bcel/TODO.JustIce,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TODO.JustIce 2 Mar 2002 19:55:59 -0000 1.2
+++ TODO.JustIce 9 Mar 2002 22:30:15 -0000 1.3
@@ -1,11 +1,19 @@
-$Id: TODO.JustIce,v 1.2 2002/03/02 19:55:59 enver Exp $
+$Id: TODO.JustIce,v 1.3 2002/03/09 22:30:15 enver Exp $
"TODO" list for JustIce, the Java Class File Verifier by Enver Haase.
- JustIce uses object generalization during pass 3b, as supposed by
Sun. However, there are better methods such as the idea proposed by
-Staerk et al.: using sets of object types.
+Staerk et al.: using sets of object types. JustIce may reject code
+that is not rejected by traditional JVM-internal verifiers for this
+reason. The corresponding checks all have some "TODO" tag with an
+explanation; they're all in the 'InstConstraint.java' file. Users
+encountering problems should simply comment them out (or uncomment
+them) as they like. The default is some setting that works well
+when using 'java org.apache.bcel.verifier.TransHull java.lang.String'
+- that is, there are no rejects caused by the above problem in a lot
+of usual classes.
- There are a few bugs concerning access rights of referenced methods
and probably fields. The tests for access rights that Sun defines
1.3 +12 -12 jakarta-bcel/src/java/org/apache/bcel/verifier/structurals/InstConstraintVisitor.java
Index: InstConstraintVisitor.java
===================================================================
RCS file: /home/cvs/jakarta-bcel/src/java/org/apache/bcel/verifier/structurals/InstConstraintVisitor.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- InstConstraintVisitor.java 4 Feb 2002 09:06:40 -0000 1.2
+++ InstConstraintVisitor.java 9 Mar 2002 22:30:15 -0000 1.3
@@ -84,7 +84,7 @@
* TODO: Currently, the JVM's behaviour concerning monitors (MONITORENTER,
* MONITOREXIT) is not modeled in JustIce.
*
- * @version $Id: InstConstraintVisitor.java,v 1.2 2002/02/04 09:06:40 enver Exp $
+ * @version $Id: InstConstraintVisitor.java,v 1.3 2002/03/09 22:30:15 enver Exp $
* @author <A HREF="http://www.inf.fu-berlin.de/~ehaase"/>Enver Haase</A>
* @see org.apache.bcel.verifier.exc.StructuralCodeConstraintException
* @see org.apache.bcel.verifier.exc.LinkingConstraintException
@@ -1758,9 +1758,9 @@
ReferenceType rFromDesc = (ReferenceType) fromDesc;
// TODO: This can only be checked using Staerk-et-al's "set of object types", not
// using a "wider cast object type".
- //if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ){
- // constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack (which is not assignment compatible).");
- //}
+ if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ){
+ constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack (which is not assignment compatible).");
+ }
}
else{
constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack.");
@@ -1836,11 +1836,11 @@
if (fromStack instanceof ReferenceType && fromDesc instanceof ReferenceType){
ReferenceType rFromStack = (ReferenceType) fromStack;
ReferenceType rFromDesc = (ReferenceType) fromDesc;
- // TODO: This check can only be done using Staerk-et-al's "set of object types"
+ // TODO: This check can possibly only be done using Staerk-et-al's "set of object types"
// instead of a "wider cast object type" created during verification.
- //if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ){
- // constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack (which is not assignment compatible).");
- //}
+ if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ){
+ constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack (which is not assignment compatible).");
+ }
}
else{
constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack.");
@@ -1882,11 +1882,11 @@
if (fromStack instanceof ReferenceType && fromDesc instanceof ReferenceType){
ReferenceType rFromStack = (ReferenceType) fromStack;
ReferenceType rFromDesc = (ReferenceType) fromDesc;
- // TODO: This can only be checked when using Staerk-et-al's "set of object types" instead
+ // TODO: This can possibly only be checked when using Staerk-et-al's "set of object types" instead
// of a single "wider cast object type" created during verification.
- //if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ){
- // constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack (which is not assignment compatible).");
- //}
+ if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ){
+ constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack (which is not assignment compatible).");
+ }
}
else{
constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+"' on the stack.");
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>