develooper Front page | perl.perl5.porters | Postings from February 2003

Re: New SV Flag

Thread Previous | Thread Next
From:
Arthur Bergman
Date:
February 5, 2003 23:28
Subject:
Re: New SV Flag
Message ID:
5B49BFF8-39A4-11D7-9C2D-003065D64CBE@contiller.se

On onsdag, feb 5, 2003, at 23:09 Europe/Stockholm, Nicholas Clark wrote:

> On Mon, Feb 03, 2003 at 01:14:59AM +0100, Arthur Bergman wrote:
>> Hi,
>>
>> I would like a new SV flag, or SV flag combination that means, this SV
>> does not live on the arenas and should not be PL_sv_counted, a hint to
>> sv_free not to plant this sv again.
>
> What do you mean plant? particularly with respect to sv_free?
>

When a sv is freed, a macro called plant_SV is called.

#define plant_SV(p) \
     STMT_START {                                        \
         SvANY(p) = (void *)PL_sv_root;                  \
         SvFLAGS(p) = SVTYPEMASK;                        \
         PL_sv_root = (p);                               \
         --PL_sv_count;                                  \
     } STMT_END

Now, if the SV is allocated by an external malloc, I don't want the 
pointer to go into PL_sv_root, and I don't want PL_sv_count to be 
killed off.

I wonder if there is a way to do this with magic but I think no matter 
what is done in the magic destructor, perl will continue to go on. 
Basically I want a flag that says, sv_free, don't free this SV, call 
the magic destructor and then don't do anything more.


>> I would like all SVs that are living in the optree to be of this kind,
>> this would allow us to move constants out of the pad and let them be
>> PVMG so they can't be upgraded anymore, same applies for the
>> METHOD_NAMED SvPVIV.
>
> I can't see any free flags. Which flags logically conflict with this - 
> is
> there a sane way to overload one?
>
> If that fails, I can see a way to free up one flag bit - change
>
> #define SVf_OOK		0x00200000	/* has valid offset value */
> #define SvOOK(sv)		(SvFLAGS(sv) & SVf_OOK)
>
> to
>
> #define SVf_OOK		0x80000000	/* has valid offset value */
> #define SvOOK(sv)		((SvFLAGS(sv) & (SVp_IOK|SVf_OOK)) == SVf_OOK)
>
> because you can't be SVf_IVisUV:
>
> #define SVf_IVisUV	0x80000000	/* use XPVUV instead of XPVIV */
>
> without also being SVp_IOK
>

That is just ugly ;)

OTOH I notice this.

grep -r "SvOOK_on" *
Changes5.005:             Subject: [PATCH] Remove some rendundant 
SvOOK_on tests
sv.h:#define SvOOK_on(sv)               ((void)SvIOK_off(sv), 
SvFLAGS(sv) |= SVf_OOK)


And that is the only hit on SvOOK_on I get, however it seems like 
pp_substr does turn on SvOOK, but sure beats me how.

perl -MDevel::Peek -le '$a = 'foo'; substr($a, 0, 1, ""); Dump($a)'

Arthur


Thread Previous | 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