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. | [reply] [Watch: Dir/Any] [d/l] [select] |
expanding on AnomalousMonk's code and haukex's, it does seem like the sig handler has something to do with this. It appears to be activating the NV slot of the scalar.
When perl then does its DWIM conversions, it is preferring the double over the int, so I would percieve that the scalar is something a little more complex than just a dualvar.
Also worth noting sig handling on some operating systems are implemented differently. how much impact this is having I am unsure of
use strict;
use warnings;
use Devel::Peek;
$|++;
my @TEST_VALUES = ('a55','55a');
foreach my $i (@TEST_VALUES)
{
print qq{\nCalling TEST('$i') / \n};
print qq{\nTEST return values = @{[ TEST($i) ]} \n\n};
}
sub TEST
{
my $N = shift;
local $SIG{__WARN__} = sub { $|++; print "in_warn\n";
# my $subref = sub { $|++; print "in_subref\n";
Dump $N;
print qq{(warn: N=$N -> };
$N = 77;
print qq{N=$N) / \n};
Dump $N;
print "outta_subref\n";
};
print "in_test\n";
Dump $N;
# my $tmp_value = $subref->();
print qq{N=$N / N+0=}, $N + 0;
print qq{ / N.''=}, $N.'', qq{\n};
print "outta_test returning $N, $N+0, $N.''\n";
return $N, $N+0, $N.'';
}
=head1 output
Calling TEST('a55') /
in_test
SV = PV(0x10a847c) at 0xf9d3dc
REFCNT = 2
FLAGS = (PADMY,POK,pPOK)
PV = 0xf9055c "a55"\0
CUR = 3
LEN = 12
in_warn
SV = PVNV(0x10a9bcc) at 0xf9d3dc
REFCNT = 2
FLAGS = (PADMY,POK,pPOK)
IV = 0
NV = 0
PV = 0xf9055c "a55"\0
CUR = 3
LEN = 12
(warn: N=a55 -> N=77) /
SV = PVNV(0x10a9bcc) at 0xf9d3dc
REFCNT = 2
FLAGS = (PADMY,IOK,POK,pIOK,pPOK)
IV = 77
NV = 0
PV = 0xf9055c "77"\0
CUR = 2
LEN = 12
outta_subref
N=a55 / N+0=0 / N.''=77
outta_test returning 77, 77+0, 77.''
TEST return values = 77 0 77
Calling TEST('55a') /
in_test
SV = PVNV(0x10a9bcc) at 0xf9d3dc
REFCNT = 2
FLAGS = (PADMY,POK,pPOK)
IV = 0
NV = 0
PV = 0xf9055c "55a"\0
CUR = 3
LEN = 12
in_warn
SV = PVNV(0x10a9bcc) at 0xf9d3dc
REFCNT = 2
FLAGS = (PADMY,POK,pPOK)
IV = 0
NV = 55
PV = 0xf9055c "55a"\0
CUR = 3
LEN = 12
(warn: N=55a -> N=77) /
SV = PVNV(0x10a9bcc) at 0xf9d3dc
REFCNT = 2
FLAGS = (PADMY,IOK,POK,pIOK,pPOK)
IV = 77
NV = 55
PV = 0xf9055c "77"\0
CUR = 2
LEN = 12
outta_subref
N=55a / N+0=55 / N.''=77
outta_test returning 77, 77+0, 77.''
TEST return values = 77 55 77
=cut
| [reply] [Watch: Dir/Any] [d/l] |
but I suspect it has something to do with the inherent dualvar nature of scalars (see Scalar::Util::dualvar): a scalar caches a string or numeric representation of its value if it was ever used as a string or number, and both representations may be present in the scalar at the same time and may represent entirely unrelated values!
Wow, that is clever! So, it's not really a bug...! | [reply] [Watch: Dir/Any] |