This bug is just a minor annoyance, but it can slow down debugging if one is not aware of it, so I thought I'd share. The following snippets illustrates it:
if ( 0 ) {
;
}
elsif ( die __LINE__ ) {
;
}
If you run it as written, the output is:
4 at buggy.pl line 1.Note that the line reported by die is incorrect. The same bug exists with warn, and with warnings in general. E.g.
use warnings;
if ( 0 ) {
;
}
elsif ( "$_" ) {
;
}
__END__
Use of uninitialized value in string at ../test.pl line 2.
Stuff happens.
Update: the above examples were run with perl 5.8.6. I haven't looked at other versions. YMMV.
the lowliest monk
Well, "makes sense" because I know what's going on behind the scenes. :)
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
As a way of illustrating this point, here's the OP's first code block after being run through perl -MO=Deparse buggy.pl:
if (die '4') {
();
}
The [cpan://B::Deparse] module (called by the above command) shows you the Perl equivalent of what the interpreter sees at runtime. This is extremely useful for finding this "compile-time vs. run-time" class of behaviors.
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law
Congratulations on finding one of the oldest recorded Perl bug!
The cause is related to how perl interprets Perl code. The easiest explanation comes from Perlbug ticket #1034 by Ilya Zakharevich.
Diagnostic messages read the line-number-of-currently-executed-chunk-of-code from some memory location. This memory location should be reset when flow of execution winds around. It is reset at the beginning of each statement. Resetting it more often would slow things down, keeping the line-number at each opcode would take a lot of memory.