TARG has some subtleties, mention them

[tonycoz]

Mostly lessons learned from #22784.

---

• This set of changes does not require a perldelta entry.

[jkeenan]

Style nits; do not know enough to review content.

[bulk88]

I WOULD NOT document this, since its a bug IMO, and fixable but the SV* TARG that ALL FIRSTKEY NEXTKEY XSUBs get during an tied Hash iteration loop, that TARG addr never changes, and things blow up/bug out if you write to whatever you get from dXSTARG; inside a FIRSTKEY NEXTKEY XSUB.

I instead realized, probably this is UB/not public API, but inside a sub NEXTKEY ($this, $lastkey);, I can reuse/write over the SV* $lastkey incoming arg, and make it my ST(0) retval SV* outgoing arg, and not do the SV head allocing and SVPV body allocing and mortal stack/flag adding dance.

[leonerd]

These seem reasonable points to mention, so LGTM. Not sure what bulk88 is talking about with NEXTKEY there.

[bulk88]

These seem reasonable points to mention, so LGTM. Not sure what bulk88 is talking about with NEXTKEY there.

Disregard. I was wrong, sub FIRSTKEY/sub NEXTKEY are incapable of getting a if(PL_op->op_private & OPpENTERSUB_HASTARG) targ = PAD_SV(PL_op->op_targ)); b/c the PP-ish tie() API uses vanilla call_sv(), not PP callers or sort()/goto &othersub; or other direct XSUB func ptr invokers.

I checked the biz code where I encountered it some months ago, and I was remembering my code comments incorrectly in my head from what I wrote at that time. My src code comments were talking about the well known "TARG with SvROK() no DESTROY call too long lifespan" bug/API nuance. Then discussed something else. They didn't say anything about a useless TARG/op_targ idx from PL_op struct, being seeing by sub FIRSTKEY/sub NEXTKEY/sub FETCH.

I might've been thinking about a failed unrealistic experiment with TIEHASH+PP sub AUTOLOAD that doesn't vivify CVs into GVs and instead keeps lexical XSUBs around. The optimization experiment was too crazy and too slow to be useful.

Some experimenting from just now
fknktarg.pl.txt

The gv_fetch()/gv_stash/pp_method_named() code paths that in blead that eventually get the CV* for sub AUTOLOAD, PP or XS, have gotten zero attempts at optimizing them since AUTOLOAD was added

a0d0e21

Larry Wall [email protected] -10/17/1994 7:00:00 PM - perl 5.000

Except for the 5.7.0 2001 XSUB get the AU name inside their CV*'s SvPVX() optimization 8fa6a40

No SVPVHEK * of the string "AUTOLOAD" exists in the interp, its rehashed constantly. 2nd, AUTOLOAD named non-prototyped XSUB CV* get a brand new Newx() block with a copy of their future/nee GvNAME_HEK(), instead of a fast PV COW RC++ copy created from GvNAME_HEK(). 3rd strings "AUTOLOAD" and HEK_KEY(GvNAME_HEK()) are constantly resanitized for "*'::"chars when they are RO strings.