So, new problem I have found based on the change to restoring $@, $!, and
$?.

perl-bleads ext/XS-APItest/t/svpeek.t has 2 test failures.

One tests $! and it *looks like* it assumes something recently looked at $!
from a string context:

like (DPeek ($!), qr'^PVMG\("', '$!');


I can fix the test like this:

  # This tests expects that $! will have been used as a string recently.
>   my $foo = "$!";
> like (DPeek ($!), qr'^PVMG\("', '$!');


The other checks $? and *looks like* it verifies it has not been looked at
by anything:

if ($^O eq 'VMS') {
>   # VMS defines COMPLEX_STATUS and upgrades $? to PVLV
>   is (DPeek ($?),    'PVLV()', '$?');
> } else {
>   is (DPeek ($?),    'PVMG()', '$?');
> }


This can be fixed by a similar trick (not tested in vms as I have no vms
system):

if ($^O eq 'VMS') {
>     local $?; # Reset anything Test::* has done to it.
>   # VMS defines COMPLEX_STATUS and upgrades $? to PVLV
>   is (DPeek ($?),    'PVLV()', '$?');
> } else {
>     local $?; # Reset anything Test::* has done to it.
>   is (DPeek ($?),    'PVMG()', '$?');
> }


This was never a problem when we localized $! and $@. But now that we are
reading the current value, then restoring it, we no longer preserve the
internals of the variables, just the surface values.

This is the only test I have found broken by this. A test in the perl test
suite itself. I have not found anything on cpan broken by this, but my
testing is not a full smoke.

I am just reaching out to see if anyone predicts this is an *actual*
problem? Is it just as simple as updating the 1 failing test and calling it
good, or is this actually a scary thing? If it is scary, then I would love
pointers on how I can actually preserve the internal state of the variables
as well as their value, but I would really prefer not to do that if I do
not have to.

-Chad

On Mon, Jan 18, 2016 at 12:39 AM, Aristotle Pagaltzis <pagalt...@gmx.de>
wrote:

> * Chad Granum <exodi...@gmail.com> [2016-01-18 06:55]:
> > Which behavior do you want, preserve one, preserve all, preserve what
> > is requested in arguments?
>
> I didn’t consider that. I was thinking ->release would take an optional
> bool flag and that’s all. But you’re right that this would not be enough
> and that providing enough interface to cover all the cases makes it too
> complicated to be worth it.
>
> >     my $err = $@;
> >     $ctx->release();
> >     $@ = $err;
>
> Heh, which implies an obvious and amusing improvement:
>
>     { local $@; $ctx->release }
>
> Which is *easier* than any special interface, too. So, scrap that.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>

Reply via email to