Front page | perl.perl5.porters |
Postings from April 2008
On Fri, 25 Apr 2008, Marc Lehmann wrote:
> On Fri, Apr 25, 2008 at 05:20:48PM -0700, Jan Dubois <jand@activestate.com> wrote:
> > I don't think a CPAN module should _ever_ check the private flags. They
> > are for core Perl usage only. At least that's how it used to be. Isn't
> > checking SvPOK() before accessing SvCUR() doing the right thing for you?
>
> upgrading to a PV was always doing the right thing for me. The code in
> question seems to dot he right thing, too, in all perl releases I have
> tried, including 5.10.
>
> I also don't really think that SvPOK must be true to acecss SvCUR of a PV.
> Doesn't make much sense to me.
What is the meaning of SvCUR() if your SV is just SvROK() and the PVX
slot contains a reference to another SV instead of a string buffer?
perl -MDevel::Peek -e "$a='foo'; $a=\$b; Dump $a"
SV = PV(0x226f24) at 0x182a21c
REFCNT = 1
FLAGS = (ROK)
RV = 0x182a32c
SV = NULL(0x0) at 0x182a32c
REFCNT = 2
FLAGS = ()
PV = 0x182a32c ""
CUR = 0
LEN = 0
SvCUR() is supposed to return the "length of the string in the SV",
but when SvPOK() is not set, then there is no string in the SV, so
the concept of a current length doesn't make any sense. What do you
expect the semantics of SvCUR() to be in this case? Note that SvCUR()
is not actually the length of the string if you would print the SV,
which would print " SCALAR(0x182a32c)" and not the empty string "".
The SvLEN() field however does have a meaning, even when SvPOK() isn't
set: when SvLEN() is non-zero, then the buffer pointed to by PV must be
freed using Sysfree() when the SV refcount goes to 0 (and that a buffer
of SvLEN() bytes is already available for you if you want to turn
SvPOK() on).
Cheers,
-Jan
Thread Previous
|
Thread Next