Why does version->parse fail to work without preceding print?
I have to admit, this one has me foxed.
Consider this code:
use version;
use Data::Dumper;
my $codeLevel = q{6.1.0.7 (build 25.3.1103030000)};
print STDERR qq{$codeLevel\n};
my $vrmf;
if($codeLevel =~ /^\s*([0-9.]*) \(build.*\)/) {
print STDERR "$1\n";
$vrmf = version->parse($1);
}
print STDERR Dumper($vrmf);
The output, as expected, is:
6.1.0.7 (build 25.3.1103030000)
6.1.0.7
$VAR1 = bless( {
'original' => '6.1.0.7',
'qv' => 1,
'version' => [
6,
1,
0,
7
]
}, 'version' );
However, remove the second print:
use version;
use Data::Dumper;
my $codeLevel = q{6.1.0.7 (build 25.3.1103030000)};
print STDERR qq{$codeLevel\n};
my $vrmf;
if($codeLevel =~ /^\s*([0-9.]*) \(build.*\)/) {
$vrmf = version->parse($1);
}
print STDERR Dumper($vrmf);
The output becomes:
6.1.0.7 (build 25.3.1103030000)
$VAR1 = bless( {
'original' => '0',
'version' => [
0
]
}, 'version' );
I can't find any documentation that says that print
can affect variables passed to it, or that 开发者_如何学Cit affects the regex matching variables.
Can someone explain to me what is happening here, please?
Scalar values in Perl can be a number and a string at the same time. An SV object (SV = Scalar Value) has slots for integer, float, and string values and flags identifying which of those values are valid at any point in time. When you use a value as a string perl calculates the string value and sets a flag identifying it as valid. (Other operations, like adding 1 would invalidate the string value.) When you print something you're (unsurprisingly) using it as a string. You can see this using Devel::Peek.
use Devel::Peek;
my $s = '6.1.0.7 (build 25.3.1103030000)';
if ($s =~ /^\s*([0-9.]*) \(build.*\)/) {
Dump($1);
printf STDERR "\$1 = $1\n";
Dump($1);
}
The result is
SV = PVMG(0x1434ca4) at 0x144d83c
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x146c324
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x144d82c
MG_LEN = 1
MG_PTR = 0x14631c4 "1"
$1 = 6.1.0.7
SV = PVMG(0x1434ca4) at 0x144d83c
REFCNT = 1
FLAGS = (GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x1487a1c "6.1.0.7"\0
CUR = 7
LEN = 8
MAGIC = 0x146c324
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x144d82c
MG_LEN = 1
MG_PTR = 0x14631c4 "1"
Note that in the second dump output the PV slot (string value) has been populated and the pPOK flag has been added under FLAGS.
So, yes, print
has side-effects of a sort although under normal circumstances you should never notice. version->parse()
appears to expect a string argument but isn't triggering string semantics. Given that version
prefers to use an XS implementation, it's probably a bug there rather than in perl. Note that making a copy of the capture data causes the problem to disappear:
use Data::Dump qw'pp';
my $s = '6.1.0.7 (build 25.3.1103030000)';
if ($s =~ /^\s*([0-9.]*) \(build.*\)/) {
my $x = $1;
pp(version->parse($x));
}
Result:
bless({ original => "6.1.0.7", qv => 1, version => [6, 1, 0, 7] }, "version")
Looks like a bug in version::parse, that it isn't properly triggering get magic on the incoming parameter.
Looking at the code shows the same problem in the CPAN and core "versions"; it's checking SvOK long before handling get magic. Unfortunately, this will involve a fix both in the module code and the perl core.
This reproduces with Perl 5.14.1 on MacOS X 10.6.8, using the XS implementation of 'version' 0.91 (that's version version 0.91)...
However, it is a bug in the version::vxs
(XS implementation), not the version::vpp
(pure Perl) implementation.
use version::vxs;
use Data::Dumper;
my $codeLevel = q{6.1.0.7 (build 25.3.1103030000)};
print STDERR qq{$codeLevel\n};
my $vrmf;
if($codeLevel =~ /^\s*([0-9.]*) \(build.*\)/) {
$vrmf = version::vxs->parse($1);
}
print STDERR Dumper($vrmf);
That fails as you showed. When I compiled the pure Perl version (perl Makefile.PL --perl_only
, as mentioned in the README file), and tested it, it worked correctly:
$ perl -Iblib/lib x4.pl
6.1.0.7 (build 25.3.1103030000)
$VAR1 = bless( {
'original' => '6.1.0.7',
'qv' => 1,
'version' => [
6,
1,
0,
7
]
}, 'version::vpp' );
$ cat x4.pl
use version::vpp;
use Data::Dumper;
my $codeLevel = q{6.1.0.7 (build 25.3.1103030000)};
print STDERR qq{$codeLevel\n};
my $vrmf;
if($codeLevel =~ /^\s*([0-9.]*) \(build.*\)/) {
$vrmf = version::vpp->parse($1);
}
print STDERR Dumper($vrmf);
$
I think you could sensibly report this on CPAN RT (the author is JPEACOCK). As a workaround, manually install the pure Perl version and remove the XS version (because the code looks for the XS code first - see version-0.91/lib/version.pm
). If you're really brave, consider working out what the actual bug is.
Isn't it always the way; you ask a question and then find the answer!
This code:
use version;
use Data::Dumper;
my $codeLevel = q{6.1.0.7 (build 25.3.1103030000)};
print STDERR qq{$codeLevel\n};
my $vrmf;
if($codeLevel =~ /^\s*([0-9.]*) \(build.*\)/) {
$vrmf = version->parse("$1");
}
print STDERR Dumper($vrmf);
Works correctly. Note that $1 has been stringified here.
Still, that leaves an interesting observation: that printing a variable seems to permanently stringify it!
I don't know the particular magic behind version numbers, but with overload
you can give practically any side-effect you want to stringification.
package My::Class;
use overload
'""' => \&arbitrary_function;
...
$obj = My::Class->new();
print $obj; # invokes &arbitrary_function
精彩评论