Fix perl_call_*() when !G_EVAL
authorGurusamy Sarathy <gsar@engin.umich.edu>
Tue, 25 Feb 1997 07:25:56 +0000 (02:25 -0500)
committerChip Salzenberg <chip@atlantic.net>
Tue, 25 Feb 1997 01:12:02 +0000 (13:12 +1200)
commit40f788c454d994616342c409de5b5d181ad9b8af
tree0d0cd72da359a1854e8b42977bbf25a3782f7500
parent2f9daededa74ef1264bd2c46743008f84bff0cfc
Fix perl_call_*() when !G_EVAL

On Mon, 24 Feb 1997 15:19:17 EST, Gurusamy Sarathy wrote:
>On Mon, 24 Feb 1997 12:53:57 GMT, Tim Bunce wrote:
>>> From: Tom Christiansen <tchrist@jhereg.perl.com>
>>> >Dprof "works".
>>> Then how come it's not in the core? :-(
>>I'd certainly like it to be there for 5.004.
>
>I'd agree, except there's this bug in perl_call_*() that makes
>it fail to run this fully:
>
>   % perl -d:DProf -e 'sub T { eval { die "burp" } } T(); print "zip\n"'
>   %

Ok, here's a patch for the perl_call_*() problems with error traps,
meant for 5.004 (hope I didn't miss the boat!).

This is a subset of the functionality contained in Michael Schroeder's
stack-of-stacks patch.  The patch itself if simple: code that calls
runops() without explicitly setting up a jmp_buf sets a flag that
indicates doeval() is responsible for catching any longjmp()s
locally.  The three places that call doeval() then call setjmp()
based on this flag.

This patch is binary compatible and minimal (as opposed to the
stack-of-stacks patch which has other issues involved, making it
more complicated).  There's a testsuite with 9 tests (3_28 fails all
but one).

p5p-msgid: <199702250725.CAA09192@aatma.engin.umich.edu>
gv.c
interp.sym
perl.c
perl.h
pp_ctl.c
pp_sys.c
t/op/runlevel.t [new file with mode: 0644]