Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
The question is whether this hit (e.g. magic retrieval) is wanted for the general case. APR::Table is
OK- how about using SvFAKE for the APR::Table return values instead?
That way everybody wins- APR::Tables uses copy-on-write for the returned SV's (which is faster than doing newSVpv), and apreq can get the metadata back by interrogating those SV's (since they're not copies, so SvPVX(sv) still points to the original data[1]).
I've checked that it's in 5.6.0 (The minimum that we need to support), though I'm not sure if it's working right. I haven't used it myself, but there is a lot of info in the thread starting from this post:
http://archive.develooper.com/[EMAIL PROTECTED]/msg96172.html
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
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?
Besides that, once SvFAKE what happens if users try to modify it?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
