perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [rfc] APR::Table & polymorphic values
Date Tue, 03 Jun 2003 10:54:42 GMT
Stas Bekman <stas@stason.org> writes:

[...]

> http://archive.develooper.com/perl5-porters@perl.org/msg96172.html

Thanks for the link!

> I haven't read the whole thread, but saw Tim Bunce suggesting later in
> this thread not to use SvFAKE:
> http://archive.develooper.com/perl5-porters@perl.org/msg95102.html

Using SvLEN = 0 seems to be the cleanest solution.  Unfortunately,
setting SvLEN = 0 prevents correct sv_2iv conversion w/ 5.8.  The bug 
is caused by testing for SvLEN > 0 instead of SvCUR > 0 in Perl_sv_2iv. 
I don't know if bleadperl has fixed this, but it's probably behaved 
this way for quite a while.

> May be all you need is to manipulate the pointers. So in normal case
> SVPV will point to the first char, in apreq case it'll point to the
> char the real data starts from. Am I shooting far off the target?

In the normal case:

   sv = newSVpv(data,0);

perl mallocs space for a copy and does a strcpy(SvPVX(sv), data).  
That's not good enough for apreq- we really need SvPVX(sv) == data 
in order to get at the metadata in front of &data[0].

> Besides that, once SvFAKE what happens if users try to modify it?

SvFAKE | SvREADONLY is what perl uses to mark shared sv's, so I thought
I could borrow those flags here.  Unfortunately that doesn't seem to
work very well with the tiehash table API (t/modperl/env generates
lots of "Attempt to free non-existent shared string ..." warnings).

-- 
Joe Schaefer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message