End Block with negative n corrupts the storage offset

[j4james]

According to the specification:

The } "End Block" instruction pops a cell off the stack that it calls n, then pops a vector off the SOSS which it assigns to the storage offset, then transfers n elements (as a block) from the TOSS to the SOSS, then pops the top stack off the stack stack. If n is negative, |n| cells are popped off of the (original) SOSS.

But looking at the code for fi_end, we have:

1. n is popped off the stack (line 237)
2. if n is negative, |n| cells are popped from the SOSS (lines 238-249)
3. the storage offset is restored from the SOSS (lines 251-252)
4. if n is positive, n elements are transfered from the TOSS to the SOSS (line 253)

So when n is negative, the SOSS is cleared too early, and the storage offset gets nuked before it has a chance to be restored. Basically step 3 needs to happen before step 2.

Btw, this is the reason for the Mycology error:

BAD: u with a positive argument gives strange storage offset: expected (0,0)

It's confusing because the real failure happens at the time of the negative argument test, but it's not picked up because that is just checking whether the right number of cells were removed from the stack. The right number were removed, but they were removed in the wrong order, so the storage offset got initialised with junk, and that was the cause of the u failure several tests later.