[Armin]
>> 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.
[Guido]
> 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.
That's right. Anyone who intends to "do something" here (as opposed to just
talking about it) is strongly encouraged to read the Java docs I posted a
link to last time. Their answer to my original question ("verify what,
precisely?") is "what the algorithm described here checks". As also with
Java's compile-time guarantee of "no use of uninitialized variables",
there's no attempt to solve impossible problems. Instead they give a
reasonable, conservative algorithm, and define "it's OK" as "what this
algorithm allows". The difference between that and theoretical perfection
isn't an issue in practice.
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