Jordan,
Your change at the very least improves clarity for the human reader and
it may very well disambiguate something that is up for grabs in the
compiler as well. It's a puzzle why others haven't encountered the
problem, but I say we adopt the change.
Henderson, Jordan wrote:
> It's a failure in t/pod/find, #2.
>
> I spy what I think is a problem with the test, but maybe I'm confused. Here's
> the an extract from t/pod/find.t (lines 41 through 55):
>
> ---
> if ($^O eq 'VMS') {
> $compare = lc($compare);
> $result = join(',', sort values %pods);
> my $undollared = $Qlib_dir;
> $undollared =~ s/\$/\\\$/g;
> $undollared =~ s/\-/\\\-/g;
> $result =~ s/$undollared/pod::/g;
> my $count = 0;
> my @result = split(/,/,$result);
> my @compare = split(/,/,$compare);
> foreach(@compare) {
> $count += grep {/$_/} @result;
> }
> ok($count/($#result+1)-1,$#compare);
> }
> ---
>
> Now, my debuggin shows $count == 0, even though I do show that the string in $_
> at line 52 is in @result. Now, grep modifies $_ with the elements found in
> @result. Is this potentially undefined behavior? 'perldoc -f grep' says:
>
<snipped>
> So, $_ above is first aliased to an element of @compare and then it gets aliased
> to an element of @result. Tricky. If these things aren't done in the "right"
> order (what order is right?), then bazaare things could happen.
>
> if I change the foreach loop to:
>
> ---
> foreach $compare (@compare) {
> $count += grep {/$compare/} @result;
> }
> ---
>
> It seems to work.
