use Devel::Peek;
use strict;
no warnings "numeric";
sub xx {
    my $arg=shift;
    Dump( $arg );
    print "ARG+1=".($arg+1)."\n";
}
xx("ff");
xx(7);
xx("ff");
__END__

SV = PV(0x729b78) at 0x754ae0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x747d90 "ff"\0
  CUR = 2
  LEN = 8
ARG+1=1
SV = PVNV(0x72b5f0) at 0x754ae0
  REFCNT = 1
  FLAGS = (PADMY,IOK,pIOK)
  IV = 7
  NV = 0
  PV = 0x747d90 "ff"\0
  CUR = 2
  LEN = 8
ARG+1=8
SV = PVNV(0x72b5f0) at 0x754ae0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  IV = 7
  NV = 0
  PV = 0x747d90 "ff"\0
  CUR = 2
  LEN = 8
ARG+1=1
[download]

It's not the operation, it is whether the argument is forced from numeric to string.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

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 &:

use Devel::Peek;
use strict;
no warnings "numeric";

sub xx {
        my $arg = shift;
        my $const = "";
        print "(" . ($arg & $const) . ")\n";
}

xx("ff");
xx(7);
xx("ff");
[download]

This code gives:

SV = PV(0x100802558) at 0x1008474e0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x1002074f0 "ff"\0
  CUR = 2
  LEN = 8
()
SV = PVIV(0x100803c58) at 0x1008474e0
  REFCNT = 1
  FLAGS = (PADMY,IOK,pIOK)
  IV = 7
  PV = 0x1002074f0 "ff"\0
  CUR = 2
  LEN = 8
(0)
SV = PVIV(0x100803c58) at 0x1008474e0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  IV = 7
  PV = 0x1002074f0 "ff"\0
  CUR = 2
  LEN = 8
()
[download]

This code gives:

Not without a call to Dump it doesn't :)