> > If arbitrary branching patterns are allowed, then in order to ensure > > absence of stack overflow/underflow, etc., it will be necessary to do > > things like proving that certain loops can't execute more than a > > certain number of times. This smells halting-problem-complete to me. > > I think it would only need to check that any path through the loop has a no > net effect on stack depth -- before branching back to the beginning of the > loop, it must pop everything it pushed. The ASM Java bytecode generation API has a similar flow control algorithm to determine the maximum stack size for java bytecode. http://asm.objectweb.org/ It uses the visitor pattern to visit classes, methods and instructions during bytecode generation that construct a control flow graph that is used at class generation time to calculate the maximum local variables and stack depth for methods (see Label.java and CodeWriter.java in their WebCVS). his information is embedded into the class, and is used at JVM verification time when the bytecode is reanalyzed to ensure that the numbers match the actual behavior of the bytecode. I've seen a lot of concern about bytecode hacking crashing the interpreter, but the Java VM Spec goes further to state that there is a risk of exploitation. I stared at ceval for a while to see if I could pick up such a hole. It hurt. I hear Phillip Eby when he says that anyone sending bytecode over the wire agent-fasion "darn well better" write their own bytecode verifier. But in a world of massive paralleism and dynamic computing, that might not seem like such a bad feature to offer stock. Would there be an interest in at least a PEP to consider a bytecode verifier? I'd be willing to take it on, but my experience is limited to JVM bytecode and verification. -Michel
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4