Under versions before 5.14, though, I get a different result (tested on v5.10.0 darwin-thread-multi-2level, 5.10.1 i486-linux-gnu-thread-multi and 5.12.4 darwin-thread-multi-2level, which are the versions I currently can get access to):

The output of the last set of prints no longer matches the previous two sets, which suggests that there's some state being preserved between calls to the sub. It looks a bit like $arg's numeric status is somehow getting "stuck".

Putting a print inside the subroutine that prints $arg verifies that $arg is receiving the right value. Putting intermediate calls to other subroutines, or other code, in between the calls to xx doesn't seem to change anything, either.

I've trudged my way through the perldeltas between 5.12 and 5.14 and I couldn't see anything relevant, but then I don't really know what it'd come under, and I don't know much about the innards of perl, so it's possible I've completely missed something.

Can anyone shed some light on why this is happening?

Thanks!

Comment on
Mystery state (possibly about whether an argument is numeric?) being maintained across calls to a sub
Select or Download CodeReplies are listed 'Best First'.

From my slightly cargo-culty perspective on what's going on here, I think that bug looks like it - especially given that non-bitwise ops don't seem to show the weirdness, and since nor does putting the constant string in a variable before doing the &: