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.
Perl_croak(aTHX_ "panic: refcounted_he_fetch_pvn bad flags %"UVxf,
(UV)flags);
if (!chain)
- return &PL_sv_placeholder;
+ goto ret;
if (flags & REFCOUNTED_HE_KEY_UTF8) {
/* For searching purposes, canonicalise to Latin-1 where possible. */
const char *keyend = keypv + keylen, *p;
return sv_2mortal(refcounted_he_value(chain));
}
}
+ ret:
return flags & REFCOUNTED_HE_EXISTS ? NULL : &PL_sv_placeholder;
}
Use of assignment to $[ is deprecated at - line 2.
Assigning non-zero to $[ is no longer possible at - line 5.
b
+########
+# NAME $^H accidentally enabling all features
+eval 'BEGIN { $^H |= 0x1c020000 } $_ = evalbytes 12345';
+print $_||$@;
+EXPECT
+Number found where operator expected at (eval 1) line 1, near "evalbytes 12345"
+ (Do you need to predeclare evalbytes?)
+syntax error at (eval 1) line 1, near "evalbytes 12345"