The problem is perl's parser/interpretter which doesn't properly record the line number of the various bits of an if. Consider:

#! /usr/bin/perl

my $a = "foo";
if ( $a =~ m/aa/ ) {
  print "hello";
 } elsif ( nonexistant() ) {
  print "hello";
 } else { }
[download]

Which says

Undefined subroutine &main::nonexistant called at - line 4.
[download]

Basically everything in the conditions of an if statement appears to be on the same line as the if.

It sucks but it's a known issue and not likely to be fixed any time soon. If I recall correctly, the way perl currently works, to fix this would mean that each block in the if would require it's own stack frame, which is too much overhead.

This is a known issue that I beleive is being or has been or will be fixed for the next major release. But the rule the thumb for warnings and errors is to look at the line and then the general area. Perl often emits a confusing mishmash of warnings and errors which will all resolve once you find the correct one and fix it.

Yes. This is a very old and popular bug, which gets reported all the time.

Although it has been talked about on p5p, it hasn't been fixed. It’s actually a fundamental problem with the way that perl keeps track of the line number, and the proposed fix is to store the line number in every single op.

Note that the warning has nothing to do with 'strict'. In fact, if it's a warning, it cannot be caused by the strict pragma. The strict pragma throws fatal errors.

>>Yes, because the problem is with the 'if' statement (the elsif is part of the if statement).
>>
You are correct. Perl considers if..elsif..else as a complete if box. Hence it is pointing towards line number of 'if'.
I Didn't know this, this is a good tip for debuggers indeed

I find it fascinating that you're focusing on the somewhat inaccurate reporting of line numbers that "cost you time", but seem to be glossing over the fact that strict did help you find a mistake.

Yes, the behavior of the warning is sometimes strange, and that should (and will) be addressed. But ultimately, strict promises to help highlight mistakes, and it did just that. I'd guess that, overall, you still saved time by avoiding having to hunt down a logic bug later.

Update: the downvotes tell me that my tone might be mistaken. I'm not trying to be critical or insulting, I really do find it interesting that a problem that appears to cost in the short run seems to take the focus away from the fact that, despite the annoyance, strict is still a good practice. I posted this to remind novices that the benefits of strictures still outweigh their shortcomings.

Afraid I have not expressed myself clearly enough. I am all for 'strict'. Use it all the time. However this warning (and it was not even a strict warning as was pointed out) was just a bit confusing in this particular instance. Just wanted to share this information so others can avoid falling in the same trap.

Have Fun

It's a funny old world. I just commented on this exact problem over at Hash option/menu loop wierd or usefull?. Perhaps you could recast your if/elsif chain as a dispatch table.

I know of at least one old thread that discusses this issue: Weird Warning (hey, a palindromic node id!). And there are others, but I can't coax them out with a search right now.

Your warning came a couple of days too late for me... Still, I'm glad you wrote up this article, because that problem was really driving me crazy. I'm glad to know that this particular time, it really wasn't all my fault...