Front page | perl.perl5.porters |
Postings from May 2008
On Fri, Apr 25, 2008 at 05:20:48PM -0700, Jan Dubois wrote:
> On Fri, 25 Apr 2008, Marc Lehmann wrote:
> > On Fri, Apr 25, 2008 at 02:58:37PM +0100, Nicholas Clark <nick@ccl4.org> wrote:
> > > It can be fixed with the appended patch.
> >
> > This is especially troubling as the code goes to the expense of upgrading
> > to SVt_PV before. If XS code cannot use SvCUR anymore after upgrading to
> > SVt_PV then I would consider this a serious regression.
>
> I don't think you should rely on SvCUR() to have any particular value if
> SvPOK() isn't true. I don't think this was ever guaranteed.
>
> > At least the new requirement of having to check a private flag (which
> > isn't explained anywhere) before calling SVCUR even on pv's should be
> > clearly documented as a change in behaviour.
>
> 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?
I believe that it is necessary if one wants to be polymorphic based on the
type of value, if the value has magic, such as if it's tainted.
This stepping through Perl_sv_setsv_flags for perl -T -e '$a = $^X'
3448 if (SvGMAGICAL(sstr) && (flags & SV_GMAGIC)) {
(gdb)
3449 mg_get(sstr);
(gdb) n
3450 if (SvTYPE(sstr) != stype) {
(gdb) call Perl_sv_dump(my_perl, sstr)
SV = PVMG(0x810240) at 0x800e70
REFCNT = 2
FLAGS = (GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x201be0 "/Volumes/Stuff/p4perl/maint-5.8/perl/perl"\0
CUR = 41
LEN = 44
MAGIC = 0x201c10
MG_VIRTUAL = &PL_vtbl_taint
MG_TYPE = PERL_MAGIC_taint(t)
MG_LEN = 1
SvPOK(sstr) is never going to be true, even after the mg_get().
Nicholas Clark
Thread Previous
|
Thread Next