> Perhaps it's valid according to the standard, but as I argued
> previously, many real compilers need the platform to work differently.
> I showed that the stack should be considered the same at L2 as at L1,
> so there's a stack size conflict at L3. Branched from L6, the stack
> size before L3 is 1; considered top-down, the stack size before L3 is
> 2.
When browsing the code is a top-down fashion, we can't know any thing
about the stack depth before L3 ! Why are you supposing it has a stack
depth of 1 ?!!!
In fact, since it's not reachable from any previous exception, then It
just has an "unknown stack depth".
=============== ECMA-335, Partition III
1.7.5 Backward branch constraints
It shall be possible, with a single forward-pass through the CIL
instruction stream for any method, to infer the exact state of the
evaluation stack at every instruction (where by “state” we mean the
number and type of each item on the evaluation stack).
In particular, if that single-pass analysis arrives at an instruction,
call it location X, that immediately follows an unconditional branch,
and where X is not the target of an earlier branch instruction, then
the state of the evaluation stack at X, clearly, cannot be derived
from existing information. In this case, the CLI demands that the
evaluation stack at X be empty.
Following on from this rule, it would clearly be invalid CIL if a
later branch instruction to X were to have a
non-empty evaluation stack
===============
> if it were my decision, I would throw an exception that the code is
> invalid, when computing the max stack size.
Actually, I've been using of modified version of the patch I submitted
for a little while :
private void MarkNextInstruction(IntegerQueue visitedInstructions,
int[] stackSizes, int instructionIndex, int stackDepth)
{
if (instructionIndex >= stackSizes.Length)
return;
int curStackDepth = stackSizes[instructionIndex];
if (curStackDepth == -1)
{
visitedInstructions.Add(instructionIndex);
stackSizes[instructionIndex] = stackDepth;
}
else if (curStackDepth != stackDepth)
throw new Exception("Invalid IL code.");
}
By throwing exceptions when detecting a wrong instruction depth, it
helped me a lot emitting correct IL code. No need to use PEVerify
every time I introduces a small change in my code.
--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---
