diff options
author | David Mitchell <davem@iabyn.com> | 2021-10-07 17:15:47 +0100 |
---|---|---|
committer | David Mitchell <davem@iabyn.com> | 2021-10-07 17:31:33 +0100 |
commit | 07a6208729c01c230010594c3e08a946ab0ccbef (patch) | |
tree | c22730559b0cda43ef9ea337f896c6aeb0f2eb1e /NetWare/bat | |
parent | 2b0c7afada71b2d42dd50ec342a0e9878e4e2ef2 (diff) | |
download | perl-07a6208729c01c230010594c3e08a946ab0ccbef.tar.gz |
add OPpUSEINT op_private flag bit
The bitwise ops, such as a '<<', have an op_private flag that is set
when compiled within the scope of 'use integer;'.
Unfortunately, due to historical reasons, the defined flag that
indicates this bit (bit 0) is HINT_INTEGER rather than an OPpfoo define.
But HINT_INTEGER is supposed to represent a bit within PL_hints, not a bit
within op_private. If someone reorganised the flags in PL_hints at some
point, it would mess up bitwise ops.
So this commit:
1) adds a new flag, OPpUSEINT, to indicate the bit within op_private.
2) Changes this flag's value from 0x1 to 0x4 to force it to be different
than HINT_INTEGER - thus potentially flushing out any misuse of this
flag anywhere (in core or XS code).
3) tells regen/op_private that the lower two bits of op_private in bitwise
ops don't contain the argument count. They never did, but not
specifying that in regen/op_private meant that the debugging code in
op_free() never spotted the unknown bit 0 sometimes being set.
4) Also tell that debugging code to skip the test if the op is banned.
This fixes a new fail in dist/Safe/t/safeops.t which was croaking
about a banned op having an unrecognised op_private flag bit set
before ck_bitop() had a chance to delete the arg count in op_private.
Diffstat (limited to 'NetWare/bat')
0 files changed, 0 insertions, 0 deletions