Front page | perl.perl5.porters |
Postings from February 2023
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). -- RuudThread Previous | Thread Next