Front page | perl.perl5.porters |
Postings from August 2011
Re: Predeclaration vs. scalar types - no worries
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
August 13, 2011 08:46
Subject:
Re: Predeclaration vs. scalar types - no worries
Message ID:
20110813150039.GL23881@plum.flirble.org
On Fri, Aug 12, 2011 at 02:10:33PM -0700, Chip Salzenberg wrote:
> Jan asks:
> > How is this "change semantics when you pre-declare" going to work for
> internal operations like copying scalars?
>
> At the XS level, this is an incompatibility, but only a VERY TINY one that
> is even noticeable in almost no code and doesn't malfunction in evil ways
> when it does arise; so we can just document it and carry on. No need for
> zones of predeclaration or anything like that. We're taking advantage of
> the Perl's API abstraction (such as it is).
I agree that we're taking advantage of the abstraction.
> The TINY incompatibility is this:
> OLD: SvPOK() is true whenever the value was either semantically a string
> or had been incidentally stringified.
> NEW: SvPOK() is true in all the same circumstances, *except* incidental
> stringification of an IV, UV, or NV.
> UNCHANGED: Everything else, including SvPOKp() being true after
> incidental stringification, and the return values of SvPV() and family.
> This sounds like it might be trouble, but it really isn't. Think about it.
>
> The only code in the core that even noticed was some really bad hackery in
> Data::Dumper, and the fix was trivial and backward-compatible.
>
> That's it. Since SvPV() and company still work the same, if you coded to
> get a string you can still get it. And if you really care about whether
> SvPVX() is valid, then the test is still the same as it used to be:
> SvPOKp(). So no change there either.
However, I'm suspicious that there will be XS code out there which still
(wrongly) assumes that it knows how to do polymorphism, checking SvPOK()
and doing something different if it's not true, instead of calling SvPV().
Such code will already break if presented with tainted values.
Although
1) I can only remember one instance for sure when someone reported a problem
with a CPAN module doing this. So it may not be very much code
2) Such code was looking for a *string*. The situation here where SvPOK() is
(now) not set is for a number.
So for code to break, it needs to be thinking that it knows how to do
polymorphism, or that SvPOK() is the way to go, not SvPV(), *and* that the
strings that it is looking for are actually sequences of characters that are
valid numbers.
This seems unlikely.
> In short: We can just do it.
But I'd feel a lot calmer if someone were able to test build CPAN (ie as much
of it as possible for their OS etc) and compare this branch to blead, to
get a handle on how much "crazy" is out there. IIRC something similar was
done for the ExtUtils::ParseXS changes. But I'm not sure how much the favour
request costs, or whom to bribe.
Nicholas Clark
Thread Previous
|
Thread Next