[.I originally posted this to comp.lang.perl.misc. Since I can't
find it in the bug database, I am additionally sending it to
this mailing list.]
If I am in the middle of doing an /foo/bar/g loop,
and I call a function that localizes the variable which
is being searched, the "iteration context" is lost
when I return from that function back to the loop.
To demonstrate, run this program:
#!/usr/bin/perl
$foo = <<'S1';
This is a test of a possible bug in perl.
If I call a proc that localizes the same variable
that I am currently using in a global (/g) match,
perl misbehaves in a very strange manner.
It does not seem to properly restore the "iteration context"
when the proc returns from its task.
S1
sub proc {
local($foo) = <<'S2';
aaaa aaab aaac aaad aaae aaaf aaag aaah aaai aaaj
aaak aaal aaam aaan aaao aaap aaaq aaar aaas aaat
aaau aaav aaaw aaax aaay aaaz
aaba aabb aabc aabd aabe aabf aabg aabh aabi aabj
aabk aabl aabm aabn aabo aabp aabq aabr aabs aabt
aabu aabv aabw aabx aaby aabz
S2
}
while ($foo =~ /\b\w{4}\b/g) { # search for "four letter words"
print ("Match # ", ++$n, ": $&\n");
print ("Before:\n", $`, "\n\n");
print ("After: \n", $', "\n\n");
&proc();
}
In perl 4, I get very strange results. In perl 5, I loop
forever finding the first "This".
In perl 5, you can change local() to my() above to work around
the bug. BUT, this is not really a good answer in general, because
the bug is especially insidious when it strikes the
"hidden" variable $_, as in:
sub proc() {
local ($_);
...
while (<FOO>) { ... } ;
...
}
while (<>) {
...
do proc() while (/baz/);
...
}
You *cannot* say "my($_)". As a result, NO subroutine can safely
use $_ for fear of clobbering a /g context further up the call stack!!
(BTW, why doesn't perl allow "my($_)" ???)
find it in the bug database, I am additionally sending it to
this mailing list.]
If I am in the middle of doing an /foo/bar/g loop,
and I call a function that localizes the variable which
is being searched, the "iteration context" is lost
when I return from that function back to the loop.
To demonstrate, run this program:
#!/usr/bin/perl
$foo = <<'S1';
This is a test of a possible bug in perl.
If I call a proc that localizes the same variable
that I am currently using in a global (/g) match,
perl misbehaves in a very strange manner.
It does not seem to properly restore the "iteration context"
when the proc returns from its task.
S1
sub proc {
local($foo) = <<'S2';
aaaa aaab aaac aaad aaae aaaf aaag aaah aaai aaaj
aaak aaal aaam aaan aaao aaap aaaq aaar aaas aaat
aaau aaav aaaw aaax aaay aaaz
aaba aabb aabc aabd aabe aabf aabg aabh aabi aabj
aabk aabl aabm aabn aabo aabp aabq aabr aabs aabt
aabu aabv aabw aabx aaby aabz
S2
}
while ($foo =~ /\b\w{4}\b/g) { # search for "four letter words"
print ("Match # ", ++$n, ": $&\n");
print ("Before:\n", $`, "\n\n");
print ("After: \n", $', "\n\n");
&proc();
}
In perl 4, I get very strange results. In perl 5, I loop
forever finding the first "This".
In perl 5, you can change local() to my() above to work around
the bug. BUT, this is not really a good answer in general, because
the bug is especially insidious when it strikes the
"hidden" variable $_, as in:
sub proc() {
local ($_);
...
while (<FOO>) { ... } ;
...
}
while (<>) {
...
do proc() while (/baz/);
...
}
You *cannot* say "my($_)". As a result, NO subroutine can safely
use $_ for fear of clobbering a /g context further up the call stack!!
(BTW, why doesn't perl allow "my($_)" ???)