develooper Front page | perl.perl5.porters | Postings from October 2013

Re: Why does undef *gv vivify a scalar?

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
October 26, 2013 10:48
Subject:
Re: Why does undef *gv vivify a scalar?
Message ID:
20131026104845.GA26894@plum.flirble.org
On Sat, Oct 26, 2013 at 09:28:58AM -0000, Father Chrysostomos wrote:
> I thought PERL_DONT_CREATE_GVSV (the default) allowed the SV slot to
> be null internally.  pp_undef has this:
> 
>             gp_free(MUTABLE_GV(sv));
>             Newxz(gp, 1, GP);
>             GvGP_set(sv, gp_ref(gp));
>             GvSV(sv) = newSV(0);         <--- note this line
>             GvLINE(sv) = CopLINE(PL_curcop);
>             GvEGV(sv) = MUTABLE_GV(sv);
>             GvMULTI_on(sv);
> 
> Was this an oversight?

I think that it might be (but I've not tested)

The backstory is that there is a fair amount of code on CPAN which assumes
that *foo{SCALAR} is always a valid reference, and would fail with errors if
it stopped always being a scalar. So the intent of PERL_DONT_CREATE_GVSV was
to change the internals, but fake it in Perl space, as if nothing changed.

(And we couldn't see a route to get a warning cycle from what we have
currently, to code not assuming this. In that if as a first step the
interpreter warns on accessing *foo{SCALAR} that it had to autovifify it for
you, and in future it won't, then code written to be robust for the future
will get the warning anyway, even if that code then checks for undef)


But I'm thinking that at the point you've shown, there's no need to create
a new scalar. If instead it's left as NULL, do all Perl-space access to it
continue to work as expected, lazily creating the scalar at access time?


Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About