Question

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 it affects the regex matching variables.

Can someone explain to me what is happening here, please?

Answer 1

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")