Return-Path: Delivered-To: apmail-perl-dev-archive@perl.apache.org Received: (qmail 97204 invoked by uid 500); 3 Jun 2003 10:52:16 -0000 Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@perl.apache.org Received: (qmail 97136 invoked from network); 3 Jun 2003 10:52:15 -0000 Received: from main.gmane.org (80.91.224.249) by daedalus.apache.org with SMTP; 3 Jun 2003 10:52:15 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19N9MZ-0002Q1-00 for ; Tue, 03 Jun 2003 12:49:55 +0200 Mail-Followup-To: dev@perl.apache.org X-Injected-Via-Gmane: http://gmane.org/ To: dev@perl.apache.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19N9MX-0002Pr-00 for ; Tue, 03 Jun 2003 12:49:53 +0200 From: Joe Schaefer Subject: Re: [rfc] APR::Table & polymorphic values Date: 03 Jun 2003 06:54:42 -0400 Lines: 39 Message-ID: References: <3EDAED0C.507@stason.org> <3EDB0181.7040502@stason.org> <3EDC4A35.8010000@stason.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stas Bekman 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