This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Stop $^H |= 0x1c020000 from enabling all features
authorFather Chrysostomos <sprout@cpan.org>
Fri, 27 Mar 2015 16:23:41 +0000 (09:23 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Fri, 27 Mar 2015 19:30:22 +0000 (12:30 -0700)
commit71622e40793536aa4f2ace7ffc704cc78151fd26
tree0c96ea53aeab1fdec2e092a1bc5c8df477b54a83
parentd1d50e3e86916d266355a8fe5c5374460f7aa033
Stop $^H |= 0x1c020000 from enabling all features

That set of bits sets the feature bundle to ‘custom’, which means that
the features are set by %^H, and also indicates that %^H has been did-
dled with, so it’s worth looking at.

In the specific case where %^H is untouched and there is no corres-
ponding cop hint hash behind the scenes, Perl_feature_is_enabled (in
toke.c) ends up returning TRUE.

Commit v5.15.6-55-g94250ae sped up feature checking by allowing
refcounted_he_fetch to return a boolean when checking for existence,
instead of converting the value to a scalar, whose contents we are not
even going to use.

This was when the bug started happening.  I did not update the code
path in refcounted_he_fetch that handles the absence of a hint hash.
So it was returning &PL_sv_placeholder instead of NULL; TRUE instead
of FALSE.

This did not cause problems for most code, but with the introduction
of the new bitwise ops in v5.21.8-150-g8823cb8, it started causing
uni::perl to fail, because they were implicitly enabled, making ^ a
numeric op, when it was being used as a string op.
hv.c
t/lib/feature/bundle