develooper Front page | perl.perl5.porters | Postings from March 2014

[perl #117341] av_undef's POD is confusing

Thread Next
From:
bulk88 via RT
Date:
March 1, 2014 06:37
Subject:
[perl #117341] av_undef's POD is confusing
Message ID:
rt-4.0.18-14798-1393655813-628.117341-15-0@perl.org
On Mon Mar 25 17:04:59 2013, davem wrote:
> On Mon, Mar 25, 2013 at 08:56:15AM -0700, bulk88 wrote:
> > . Its current POD is
> > ____________________________________________________________________
> > /*
> > =for apidoc av_undef
> > 
> > Undefines the array.  Frees the memory used by the av to store its list of
> > scalars.  If any destructors are triggered as a result, the av itself may
> > be freed.
> > 
> > =cut
> > */
> > ____________________________________________________________________
> > 
> > av_clear's POD says "Perl equivalent: C<@myarray = ();>." Wouldn't 
> > av_undef be the same thing except av_undef frees more memory than an 
> > av_clear would? So, what is the script level difference between av_clear 
> > and av_undef? none?
> 
> 
> av_clear():   @array = ()A;
> av_undef():   undef @array;
> 
> > 
> > Another problem is, " Frees the memory used by the av to store its list 
> > of scalars.  If any destructors are triggered as a result, the av itself 
> > may be freed." implies that av_undef can be used instead of calling 
> > SvREFCNT_dec/sv_2mortal. Someone else did get confused by that sentence 
> > and did think av_undef frees an AV (SV) head. I can't think of a better 
> > wording so I offer no patch. I didn't fully understand  #107440.  
> > 
> > Maybe " If any destructors are triggered as a result, the av itself may 
> > be freed." can be replaced with "If the only refcount owner of the AV *, 
> > is at the end of a chain of (circular) references that wind up owning 
> > the only AV * refcount notch, the AV * will be freeded."
> 
> That's not really right. It's not that there's a circular chain of
> references; rather that a DESTROY() method could actively free the AV
> itself, as the example in ticket showed:
> 
>     sub A::DESTROY{ $ra = 0 }
>     $ra = [ bless [], 'A' ];
>     undef @$ra;
> 
> How about:
> 
>     Warning: it is possible that the actions of a destructor called
>     directly or indirectly by freeing an element of the array, could cause
>     the array itself to be freed; so you cannot rely on C<av> still
>     pointing to a valid AV on return from the call.
> 

Looking at this ticket again. I think the warning shouldn't be there at all about av_undef and destructors and self referential destruction. Wouldn't that then apply to av_store, sv_clear and sv_setsv(sv, &PL_sv_undef) too? and every SV manipulation function that can change a reference or manipulate an aggregate (HV/AV/GV)?


-- 
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=117341

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