Craig, Good enough.
I may ask over at Perlmonks or comp.lang.perl.misc if this kind of thing evokes undefined behavior. I think we do want to know if our grep is broken in some subtle way. I'll see if I can't get a patch together soon. I haven't had sufficient tuits to go back and find out what was going on with that other system, but I strongly suspect a quota problem of some sort. It occurs to me that I'm in a good position to smoke test perl builds here. I think I have access to at least 6 and possibly more different combinations of OS's, C compilers and MMS/MMK. Hmmm... We will be upgrading those 7.1 systems soon, so we'll be back to 5 or more. Now that I think of it, I only have 3 or 4 that really wouldn't attract any attention if I ran something like this. The developers on the other configurations might complain about such a use. Only VAX I have access to these days is one I have turned off at home, though. :-( Maybe I'll try and get an automated build against the bleedperl going with my "farm". What would be a good frequency to run such a thing? How often are there new bleedperls, typically? -Jordan Henderson If you require contact information, please request it via return email. If we're not supposed to eat animals, then why are they made out of meat? -Anonymous > -----Original Message----- > From: Craig A. Berry [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 4:38 PM > To: Henderson, Jordan > Cc: 'Vmsperl (E-mail)' > Subject: Re: Building 5.8.0 problem > > > 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. > > >
