develooper Front page | perl.perl5.porters | Postings from September 2013

Re: [perl #119481] SvVALID does not check SVpad_OUR

Thread Previous | Thread Next
From:
Reini Urban
Date:
September 3, 2013 19:28
Subject:
Re: [perl #119481] SvVALID does not check SVpad_OUR
Message ID:
CAHiT=DGgO-gzNqOidf7Kns3dRD4_YSo+ROgLvrVpnQ6ipsZK_w@mail.gmail.com
On Tue, Aug 27, 2013 at 2:52 PM, Father Chrysostomos via RT
<perlbug-followup@perl.org> wrote:
> On Tue Aug 27 09:59:53 2013, rurban wrote:
>>
>> On Tue Aug 27 08:27:30 2013, rurban@cpanel.net wrote:
>> > It was safe to use B::PV->PVBM on strings, even when it was only a PV
>> > without attached Boyer-Moore table, because B::PV->PVBM had a SvVALID
>> >    check
>> > on the sv.
>> > But now the SVpad_NAME shares the same bit with SVpbm_VALID,
>> > and SvPAD_OUR = SVpad_NAME|SVpad_OUR and more.
>> >
>> > The SvVALID check misses to check for OUR and STATE and TYPED
>> > pads.
>> >
>> > #define SvPAD_TYPED_on(sv)  (SvFLAGS(sv) |= SVpad_NAME|SVpad_TYPED)
>> > #define SvPAD_OUR_on(sv)    (SvFLAGS(sv) |= SVpad_NAME|SVpad_OUR)
>> > #define SvPAD_STATE_on(sv)  (SvFLAGS(sv) |= SVpad_NAME|SVpad_STATE)
>> >
>> > but
>> > #define SvVALID(sv)         (SvFLAGS(sv) & SVpbm_VALID)
>>
>> See attached patch
>
> That patch modifies the definitions in sv.h, which isn’t going to help
> you here, because B.xs only uses SvVALID when PERL_FBM_TABLE_OFFSET is
> defined, which hasn’t been the case since before 5.16.

It doesn't help B, but it did help my code, which used SvVALID.

Even if it's not used by B it should be implemented correctly, or otherwise
the documentation has to be fixed, that SvVALID is only safe to use when the
argument is no PAD.
-- 
Reini

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About