in reply to @- Bug on the loose, lets isolate it

Of the systems I've tried (macosx 10.3.9 w/perl 5.8.1; freebsd 5.4-STABLE/amd64 and 5.4-RC4/i386 both w/perl 5.8.6), the only one that came up with the right answer (0) was the amd64 box. Everywhere else, I got different values that are ridiculously large.

When I added "$&" to the print statement, I always got the right answer, so I would assume the problem lies with the optimization that applies when "$&" is not used.

Presumably, when perl compiles a script that does not use "$&", part of what is being optimized out involves allocating some resource that is needed to store or set @-.

(updated to make last paragraph easier to read)

Another update: after seeing davido's doubts about my conclusion, and even after replying to that, I have to admit he may have a point -- I tried one other mod to the OP script: add parens around "b" in the regex, and the problem goes away. So I'll guess that there is some logic that is invoked by the need to do a capture, or the need to handle $&, that will not be invoked when neither need arises, and (for some, maybe most, perl builds) this causes the problem with using @-. But that's just a guess, in hopes that it might help the perl source-code wonks to nail this thing.

  • Comment on Re: @- Bug on the loose, lets isolate it

Replies are listed 'Best First'.
Re^2: @- Bug on the loose, lets isolate it
by davido (Cardinal) on May 30, 2005 at 07:32 UTC

    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

      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"; }
      produces:
      *** malloc_zone_malloc[14337]: argument too large: 4294967280 Out of +memory!
      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.