That's definitely a strange behavior, here's a fairly short way to reproduce it:
$ perl -wMstrict -MDevel::Peek -le 'my $x="11a"; $SIG{__WARN__} = sub{$x="99"}; print "num: ",$x+0,", str: $x"; Dump($x)' num: 11, str: 99 SV = PVNV(0x59efe266a440) at 0x59efe2692648 REFCNT = 2 FLAGS = (POK,IsCOW,pIOK,pNOK,pPOK) IV = 11 NV = 11 PV = 0x59efe26d3ae0 "99"\0 CUR = 2 LEN = 10 COW_REFCNT = 1
My guess is it's the signal handler: I am guessing it gets called during the $n+0 operation which produces the warning, and so an assignment to the string component of the variable during that operation leaves it in a state where the string and numeric components differ. So it's very similar to:
$ perl -wMstrict -MDevel::Peek -MScalar::Util=dualvar -e 'my $x=dualvar(11,"99"); Dump($x)'
I'm not sure if this is worth a bug report or not.
In reply to Re^4: Converting to number doesn't always work...
by haukex
in thread Converting to number doesn't always work...
by harangzsolt33
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |