Dan --
> While I'm not fond of segfaults myself, the place to check isn't in the
> interpreter loop. It's not unwarranted in assuming that it's told to go OK
> places. If we want to check the better place is inside the jump ops.
I'm in agreement, although we still need to watch out for falling off
the end of the bytecode block, too. Take blamo.pasm, for example. If
we caused the jump to spit out a warning instead of dying, and fall
through to the next opcode, we'd end up falling off the bytecode block
into never-never land. Now, if we know the maximum number of operands
allowed in Parrot, we could paste that many zeros on then end of the
bytecode stream so that no matter what the last thing in the input
bytecode stream is (even if its an op with its operands missing),
we'll be forcing an 'end'.
It might be nice, though, to have an op called 'err' instead of 'end'
so that if this ever happens we complain rather than just ending as
if everything was right with the world.
Do you want me to do anything like this? Or, shall I fix up the
current patch for now so we've got trace + basic protection and
then move on to smarter protection as a separate step?
Regards,
-- Gregor
_____________________________________________________________________
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_____________________________________________________________________/
