Assuming I understand your question, you're looking for a generic "Best Practices" rule you can apply to using "if-elsif" to ensure that *if* you have a warning (or die)in the "EXPR" of (one of) the elsif, *then* the line number reported for that warning (or death) will be accurate.

Is that correct?

Assuming youre requirement is to keep using if-elsif, then i don't think there's anything you can do -- short of waiting for a new version of perl that does a better job of reporting the line number.

One thing you can do, is replace all occurences of this...

elsif (EXPR) BLOCK

else { if (EXPR) BLOCK }

Using the test case from Node #42078 as an base for an example, use this instead...

#!/usr/bin/perl -w
$def = '';
undef $notdef;
if($def eq 'foo') {   # Line 4
    
} else { if ($def eq 'bar') {
} else { if ($notdef eq "RHS") { # Line 7
} } }
[download]

Personally, I don't think it's really that big a deal .. just make sure you keep in mind this problem for the future, and if you ever notice any warnings/deaths cited with a line number of some "if (EXPR)" code, then skim down and see if there's an "elsif" that might be the real culprit.

To update this to a newer version of perl, you should use warnings;. With that, you can turn off particular warnings with no warnings qw( uninitialized ); in this case. The old -w switch turns on all warnings.

Your code has a serious deficiency in that division places the left side of the string comparison in numeric context, and is then stringified to '0' by the ne operator. The right side, being undef, stringifies to an empty string. The comparison cannot succeed unless $value equals '0'.

On line numbering, you can modify perl's notion of __LINE__ and __FILE__ with the #line nnn ffff.ext directive. (Added) It follows C rules for preprocessor directives. Here's a command line example of its use:

$ perl -e'
> #line 42 bogus
> die "As expected"'
As expected at bogus line 42.
$
[download]

After Compline,
Zaxo

well I want to know that a value I expect to be initialised is undefined, so turning off this specific warning wont happen.

But much more importantly, and even of concern to you, Zaxo, is I want to know where it is happening - the sample code is specifically designed(!) to provoke the error that the wrong line number is reported - the fact that the expression's are bogus is unimportant. Imagine how much time you, Zaxo, would waste if you looked for a warning reported on line 100, when the real cause is line 400. Or that the warning is reported correctly on one platform, but is misreported on another - is it one warning?two different ones?

I want information from the monks about the warning being reported on the incorrect line, not that the code to provoke the error is deficient in some unrelated way.

<rant_mode>off</rant_mode>

update: Here's a version where I tried (and failed) to get correct line numbers reported for the error:

#!/usr/bin/perl -w
use strict;
my $string = "ABC";
my $value = undef;
if ($string =~ qr(DEF)) { # warning reported here
    print "foo";
}
# line 8
elsif ($string =~ qr(GHI)) {
    print "bar";
}
# line 11
elsif ($value/1000 ne $value) { # warning actually here
    print "baz";
}
else {
}
[download]

Abigail

if ($x) {
  print 1;
}
elsif ($x != 2) {
  print $y;
}
[download]

A similar problem is found in this case:

print 1,
2,
3,
undef,
4;
[download]

It's not going to be easy to fix this bug, methinks.

Update: but a good kludgy work-around is to use a do { ; ... } block!

if ($x) { ... }
elsif (do {; $x == 2}) { ... }
[download]

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;