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