20:29: beretboy: s/ttt/tt/g;
20:34: alienhuman: /o would make that more efficient :)
[download]

Cool. Well this bug was unknown to me when a discussion of the /o modifier came up. (Still around in 5.6.1 AS630) I whipped together a little example and discovered unknowing exactly the same bug (crazyinsomniac mentioned this thread but I didn't read it until afterwards, honest :)

At first glance though it seemed to be even wierder.

$\="\n";
$_='aaa';
my $c='a';
print "$c:$_";
print "------";
print "$c:$_" while s/$c/$c++/oe; 
print "------";
print "$c:$_";
[download]

Now by all rights this should produce the following sequence:

a:aaa
------
a:aaa
b:baa
c:bca
d:bcd
------
e:bcd
[download]

But instead produces:

a:aaa
------
b:aaa
------
b:aaa
[download]

So now if we change the statement so its ++$c we get

a:aaa
------
b:baa
c:caa
d:daa
e:eaa
f:faa
.....
[download]

Which is unlike what might be expected (even considering the /o bug) until you think about it for a second. With preincremnt The first match succeded ('aaa'=~/a/) and was replaced by itself, then $c was incremented. The second match fails ('aaa'=~/b/) and the loop stops.

So with post increment we get a match ('aaa'=~/a/) but now the replacement happens with the incremented value, so the second match ends up being ('baa'=~/b/) which is then replaced by 'c'.

I suppose this all is obvious, but I thought it was a weird enough example to add to your bug report.

Oh and you can blame:

21:45: alienhuman: /o would make that more efficient :)
[download]

:-)

Yves / DeMerphq
--
Have you registered your Name Space?