develooper Front page | perl.perl5.porters | Postings from February 2023

Re: PERL_RC_STACK branch: first cut

Thread Previous | Thread Next
"Ruud H.G. van Tol" via perl5-porters
February 28, 2023 09:45
Re: PERL_RC_STACK branch: first cut
Message ID:

On 2023-02-28 10:05, Darren Duncan wrote:
> On 2023-02-27 4:40 a.m., Ruud H.G. van Tol via perl5-porters wrote:
>> On 2023-02-27 13:17, demerphq wrote:
>>> On Mon, 27 Feb 2023 at 12:45, Ruud H.G. van Tol via perl5-porters 
>>> wrote:
>>>     I don't see (yet) how/why it should print out "foo".\
>>>     Why would you want/expect it to print "foo",
>>>     when you are using aliased parameters,
>>>     and are deliberately emptying the array?
>>> Because the scalar that holds "foo" has been pushed onto the stack 
>>> independently of the array that originally contains it. The fact 
>>> that perl aliases arguments is a key part of this bug. If the stack 
>>> was refcounted the alias would not be freed until the scalar was 
>>> popped from the stack.
>> OK, so then it (partly) comes down to what one interprets (?) as 
>> aliasing.
>> I still think it was fine to print nothing (or to complain about 
>> undefined).
>> The "prematurely freed" thing is then (IMO) another issue.
>> In my view, that free() should remain in a cleanup-queue
>> until the (intermediately undef-ed) value is no longer "busy".
>> So the "prematurely freed" is certainly a bug,
>> but he undef-ing should IMO still happen,
>> as that is just what the code does.
> I disagree that the undef-ing should still happen.
> Regardless of the implementation details of Perl, any typical 
> developer looking at the code would conceive that the $a[0] is 
> effectively making a copy of that element of @a before t() is invoked, 
> and that copy would survive even if @a itself is then emptied of 
> elements.
> So for all practical purposes the undef-ing is definitely a bug and 
> changing that behavior to not undef is a good thing, and there 
> shouldn't be any code relying on the undef-ing behavior.

I sense in this a specific notion of the vague term "undef-ing",
where IMO the term should be only about
what Perl does in (autovivify?) cases like:

perl -Mv5.28 -wE'my @x; say $x[42]'
Use of uninitialized value in say at -e line 1.

where it (by default) only warns.

-- -- -- -- --

In case of a freshly freed data structure
(if it is feasible to (lexically) detect that)
it could die in stead, to expose a bug.

But that is indeed not relevant here,
as like you say (and Yves said before),
that the $a[0]-parameter is supposed to already be fully resolved
as the scalar that "it points at/represents" at the sub-call,
well before code inside the sub messes with @a,
even in the parameter-aliasing context in that code.
IOW, no "deep-aliasing".
(and use a SCALARREF if that is what you are after)

I'm confident that the refcounting patch is on the right way
to plug such holes. Once it is in, and a bit further optimized,
there will no doubt come up interesting tie and overload and DESTROY 
cases to work out,
(for example because of existing workarounds).

-- Ruud

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About