Front page | perl.perl5.porters |
Postings from April 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. Marc, A couple of things - it was pointed out on IRC that the builds have differing -DDEBUGGING build options, and that on the other versions, the assertions which are being raised now might simply not be there. The documentation that describes that a string must be POK before you read SvCUR of it is in perlguts. Don't forget than a SV is a union of the various SV types, and that you need to check the bits to see what the meaning of the subsequent members are. Without SvPOK, you're interpreting a field that is probably not what you expect. Nicholas' use of the private member is I think a red herring - but I'm not entirely sure on that. However I think there is more to this than that - I'm also a bit confused as to why the sv_upgrade doesn't set the appropriate bits. Is it not just that the debugging version of the SvCUR macro is checking the wrong bits? Sam.Thread Previous | Thread Next