in reply to if-elsif weirdness

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. $

After Compline,

Replies are listed 'Best First'.
Re: Re: if-elsif weirdness
by leriksen (Curate) on May 21, 2003 at 05:32 UTC
    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.