Hello Tim,
On Tue, May 11, 2004 at 11:39:57PM -0400, Tim Peters wrote:
> Verifying what, precisely? (...) and that no jump tries to branch into
> the middle of some multi-byte opcode sequence
Why not? :-) (mwh can surely recommend me a psy)
> Harder to do is flow-sensitive eval stack
> simulation, to ensure that no path through the code can push more on the
> eval stack than was allocated for it, and that there's enough stuff on the
> stack at each point to satisfy each opcode that requires accessing the eval
> stack.
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.
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.
Armin
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