Substr ref anomoly (revisited)

[BrowserUk]

Can anyone understand why the two lists output by this test program are different? Note the first word of both lists.

Update: Added the references to the outputs to show they hadn't changed.

Update2: This code won't do anything useful before 5.8.3.

#! perl -slw
use strict;

my $s = 'the quick brown fox jumps over the lazy dog';

my @wordRefs;

print do{ 
    my $ref = \substr( $s, $-[ 0 ], $+[ 1 ] - $-[ 0 ] );
    push @wordRefs, $ref;
    "$ref : $$ref";
} while $s =~ m[(\S+\s*)]g;

print $/, '---', $/;

print "$_ : $$_" for @wordRefs;

__END__
P:\test>subrefs
LVALUE(0x182caf8) : the
LVALUE(0x1831624) : quick
LVALUE(0x18315d0) : brown
LVALUE(0x1824334) : fox
LVALUE(0x18243f4) : jumps
LVALUE(0x1831660) : over
LVALUE(0x1831678) : the
LVALUE(0x1831690) : lazy
LVALUE(0x18316a8) : dog

---

LVALUE(0x182caf8) : dog
LVALUE(0x1831624) : quick
LVALUE(0x18315d0) : brown
LVALUE(0x1824334) : fox
LVALUE(0x18243f4) : jumps
LVALUE(0x1831660) : over
LVALUE(0x1831678) : the
LVALUE(0x1831690) : lazy
LVALUE(0x18316a8) : dog

The first list is produced as the references are stacked. The second is produced from those same references. Why are they different?

[davido]

I get the same output from both prints (in other words, expected behavior), using ActiveState's Perl version 5.8.4 for Win32.

[BrowserUk]

Thanks. Loks like the bugs fix (5.8.3) required a bug fix:) Time to upgrade again.

[tachyon]

AS 5.6.1 behaves in a different manner. Note how the ref is always the same.....

C:\>perl test.pl
LVALUE(0x1aae9d0) : the
LVALUE(0x1aae9d0) : quick
LVALUE(0x1aae9d0) : brown
LVALUE(0x1aae9d0) : fox
LVALUE(0x1aae9d0) : jumps
LVALUE(0x1aae9d0) : over
LVALUE(0x1aae9d0) : the
LVALUE(0x1aae9d0) : lazy
LVALUE(0x1aae9d0) : dog

---

LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog
LVALUE(0x1aae9d0) : dog

C:\>perl -v

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

Binary build 635 provided by ActiveState Corp. http://www.ActiveState.
+com
Built 15:34:21 Feb  4 2003

[tadamec]

I noticed that under 5.6.1 when doing some DBI work. It took me forever to realize that every element in the @data array was actually being set to the same address.

while( my $row = $sth->fetchrow_hashref() ) {
   push @data, $row;
}

I thought it had something funky to do with the $row ref being outside of the while loop's curly-brace scope (is this a closure?). I solved the problem thusly:

while( my $ref = $sth->fetchrow_hashref() ) {
   my $row = $ref;
   push @data, $row;
}

I never saw a problem with row ordering. And, from my logic, this really shouldn't work. It reads (to me) that I'm copying the $ref reference into the $row variable, instead of creating a new reference. But, for whatever reason, the array started working the way I figured it should.

I had chalked this up as my not completely understanding the logic and scoping of references.

[BrowserUk]

Good point. I forgot to mention that it wouldn't work at all before 5.8.3, but I thought the "one lvalue per substr" bug was fixed in 5.8.3. From davidos reponse it looks like it was nearly fixed in 5.8.3 and finally fixed in 5.8.4.