Re^2: @- Bug on the loose, lets isolate it

I'm not convinced that $& is involved, I think it's just another thing that can influence the bug indirectly. I can also alter the behavior by simply adding "print @-, $/;" before the while loop. And declaring a few more lexicals before the loop changes the number too.

Dave

Comment on Re^2: @- Bug on the loose, lets isolate it Download Code

Replies are listed 'Best First'.
Re^3: @- Bug on the loose, lets isolate it by graff (Chancellor) on May 30, 2005 at 07:51 UTC
Is "changing the number" different from "getting the right answer"? If I play with putting other references to "@-" in the script, I get way different behaviors too -- e.g.: `#!/usr/bin/perl use strict; use warnings; my $string = "abc"; while( $string =~ /b/g ) { print "@-\n"; }` [download] produces: `*** malloc_zone_malloc[14337]: argument too large: 4294967280 Out of +memory!` [download] Putting other kinds of references to @- before the loop still gives me a wrong answer. In my case, it seems like the only time I get the right output is when the script uses "$&" (update: I also get the right output when I use parens in the regex). Are you able to get a right answer without this? If you just get different wrong outputs, I'd say this would be expected from a bug that is probably causing some uninitialized memory location to be used the wrong way, and the value you get can vary depending on the instructions being compiled. What matters are the conditions that distinguish correct output from wrong output.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: @- Bug on the loose, lets isolate it
by graff (Chancellor) on May 30, 2005 at 07:51 UTC

#!/usr/bin/perl
use strict;
use warnings;

my $string = "abc";

while( $string =~ /b/g ) {
    print "@-\n";
}
[download]

*** malloc_zone_malloc[14337]: argument too large: 4294967280  Out of 
+memory!
[download]

In my case, it seems like the only time I get the right output is when the script uses "$&" (update: I also get the right output when I use parens in the regex). Are you able to get a right answer without this?

If you just get different wrong outputs, I'd say this would be expected from a bug that is probably causing some uninitialized memory location to be used the wrong way, and the value you get can vary depending on the instructions being compiled. What matters are the conditions that distinguish correct output from wrong output.

[reply]
[d/l]
[select]