develooper Front page | perl.perl5.porters | Postings from December 2011

Re: Use of SvFAKE without SvREADONLY

Thread Previous
From:
Nicholas Clark
Date:
December 12, 2011 08:22
Subject:
Re: Use of SvFAKE without SvREADONLY
Message ID:
20111212162211.GT23881@plum.flirble.org
On Mon, Dec 12, 2011 at 01:05:12PM +0000, Dave Mitchell wrote:
> On Sun, Nov 27, 2011 at 02:53:47PM -0800, Father Chrysostomos wrote:
> > #define SVf_FAKE	0x01000000  /* 0: glob or lexical is just a copy
> > 				       1: SV head arena wasn't malloc()ed
> > 				       2: in conjunction with SVf_READONLY
> > 					  marks a shared hash key scalar
> > 					  (SvLEN == 0) or a copy on write
> > 					  string (SvLEN != 0) [SvIsCOW(sv)]
> > 				       3: For PVCV, whether CvUNIQUE(cv)
> > 					  refers to an eval or once only
> > 					  [CvEVAL(cv), CvSPECIAL(cv)]
> > 				       4: On a pad name SV, that slot in the
> > 					  frame AV is a REFCNT'ed reference
> > 					  to a lexical from "outside". */
> > #define SVphv_REHASH	SVf_FAKE    /* 5: On a PVHV, hash values are being
> > 					  recalculated */
> > 
> > Item 0 above says 'glob or lexical is just a copy'.  What type of
> > lexical would that be?  Is it the same as item #4?
> 
> I strongly suspect it is.

I've bene trying to remember, and I think so to. In that, I added #4,
but I can't remember for sure exactly why. I suspect that it was because
I hadn't realised that #0 meant this - a glob copy (with SvFAKE) is a very
different thing from using SvFAKE to track the ownership of a scalar.

I see that you've already updated #0

> > Are pad name SVs
> > flagged somehow so they can be identified as such in isolation (e.g., in
> > sv_setsv, etc.)?  Is it feasible to use SvFAKE without SvREADONLY to
> > indicate that SvPVX is actually the key field of a HEK, but not a shared
> > one?
>
> No, I don't think pad name SVs are detectable as such, only by virtue
> of being linked from name pads. But I think it's highly restricted
> in where they appear, and with a bit of code auditing you could probably
> make sure sure they never appear in sv_setsv etc (I would suspect
> debugging code would be the thing needing most tweaking).

I don't think that they are. (Currently)

As to unshared HEKs, no, but you've already got this in hv.h:

#define HVhek_UNSHARED	0x08 /* This key isn't a shared hash key. */

so you can use the flags on HEK_FLAGS() to tell them apart.

> 
> -- 
> The Enterprise's efficient long-range scanners detect a temporal vortex
> distortion in good time, allowing it to be safely avoided via a minor
> course correction.
>     -- Things That Never Happen in "Star Trek" #21

Exactly. If they did that, it would make the episode in question as mundane
as maintenance programming. Features are exciting and sexy.

Nicholas Clark

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About