> There are a few opcodes whose effect on the stack isn't > self-contained, like MAKE_FUNCTION which will pop N cell variables > off the stack, for N loaded from the code object which itself comes > from the stack. These ones are fun to analyse. We're planning to get rid of that one (note that it was a late addition; the original design was intended to be easy to analyze, but others didn't see the constraints). Any others that pose such problems? > Even without these, checking if a bytecode could possibly over/underflow the > stack is indeed equivalent to the halting problem; a silly example: > > <some algorithm which may stop or not> > POP_TOP > > This underflows the stack if and only if the algorithm stops. Uninteresting though, since no compiler will emit such code, and we only need to accept a reasonable subset. The same arguments could prove that Java's bytecode verification is "impossible", but nevertheless it's done. --Guido van Rossum (home page: http://www.python.org/~guido/)
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