<div dir="ltr">Hi all,<div><br></div><div>At ECLM the other week, Alessio and I agreed to start working on a requirements analysis regarding the output required for the type-checking bytecode verifier. We know Mark wants to create an intermediate level code representation to address any issues that may arise. However, we want to assess requirements first and come up with a solution after that. That solution may or may not depend on such an intermediate representation. For now, we'd like to leave that undecided.</div>
<div><br></div><div><br></div><div style>So, what I learned that the type-checking bytecode verifier wants is that it can verify the state of the stack and of the locals for all bytecode instructions.</div><div style><br>
</div><div style>In order to do so, it needs:</div><div style>1. The "initial state" of stack and locals at the external entry points of a function (ie notably the start and any exception handlers)<br></div><div style>
2. Optional "state modifications" when locals start being used or when the flow from one instruction to another is broken (such as in case of (conditional) jumps)</div><div style><br></div><div style>Apart from a different class file version number and an attribute to store this information in, that's it. More doesn't the verifier want to know.</div>
<div style><br></div><div style><br></div><div style>Is it your understanding as well that this is all that is required?<br></div><div style><br></div><div style><br></div><div>-- <br><div dir="ltr">Bye,<div><br></div><div>
Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div style>Robust and Flexible. No vendor lock-in.</div></div>
</div></div>