Stas Bekman <[EMAIL PROTECTED]> writes: [...]
> http://archive.develooper.com/[EMAIL PROTECTED]/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/[EMAIL PROTECTED]/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
