Dave Mitchell wrote:
> In the following, which is essentially the OP's code:
>
> f(1..3);
> sub f { @_ = (4..6); goto &g }
> sub g {
>
> shift;
> { package DB; my @dummy = caller(0); }
> use Data::Dumper; print Dumper(@DB::args);
> }
>
> $VAR1 is undef in 5.8.6, but is 4 in 5.8.5. This is because my patch in
> 5.8.6 maintains the reifiedness state of @_ as it is passed between two
> subs in goto &foo. Doing this avoids problems with leaking or premature
> freeing of @_ elements in nested gotos. I think this behaviour should
> remain.
I agree with this. However I've still no idea about how to fix Spiffy to
get to the first element unfreed.
> Meanwhile, there are several things that need to be, or may need to be
> fixed in caller().
>
> The first is that when caller() populates @DB::args from a reified @_
> whose AvARRAY != AvALLOC, then the first elements shouldn't point to
> freed SVs.
>
> Second, it could be argued that the DB::args behaviour of displaying the
> original @_ of the caller, rather than its current state after shifts etc,
> is wrong. In that case, it should either keep the original indices but
> replace shifted elements with undefs even in the non-reified case, or
> just show the current @_, ie don't preseve indices.
Showing the current @_ seems more logical (and less
backwards-compatible.)
> The goal with one of these last two suggestions is to remove the
> difference in behaviour seeen in DB::args depending on whether @_ has been
> reified or not. ie
>
> @_ = (1,2,3); shift @_; caller(0);
>
> should *always* set @DB::args to either (undef,2,3) or (2,3), but never
> to (1,2,3), regardless fo the reifiedness of @_.
--
We think of Rome, imperial, imperious, imperative.
-- Ulysses
