[squeak-dev] Re: Bug in BytecodeGenerator>>#jump:if:
nice
ncellier at ifrance.com
Sun Jun 22 16:17:45 UTC 2008
Klaus D. Witzel wrote:
> On Sun, 22 Jun 2008 17:16:37 +0200, Nicolas wrote:
>
>> So what would you assert about longJumpIfFalseTest?
>
> ;)
>
>> We could assert that trying to compile such a method should raise an
>> Exception (let's say a ByteCodeLimitException).
>
> No, I wouldn't do that. I'd wrap the instance of CompiledMethod into an
> InstructionStream using temps | is msg | and check it on the meta level,
> without executing the method and without the possibility that this
> crashes the VM, like
>
> (msg := is nextInstruction) selector == #pushConstant: and: [msg
> arguments = #(true)].
> (msg := is nextInstruction) selector == #jump:if: and: [msg arguments
> = #(offset false)]
>
> where offset is the one expected.
>
> /Klaus
>
>
>
Thanks, that's a nice alternative which is future proof toward Bytecode
definition change.
However, i have two objections:
1) the test would still not pass if i install a handler that can
overcome ByteCodeLimitException
2) the test won't avoid para-phrasing ByteCodeGenerator job. Because you
need to calculate the offset...
In other words, I would always prefer higher level tests if possible
(like asserting the result of execution of ifTrue:ifFalse:).
Nicolas
More information about the Squeak-dev
mailing list
|