perl - 为什么 perl 会针对有关 elsif 中使用的未初始化值的警告报告错误的行号？

Question

我收到了针对某些 Perl 代码的奇怪警告，我希望 SO-brain 可以提供帮助。

有问题的代码是:

sub add_observation {
    my $self = shift;
    my $observation = shift;

    my $result = $observation->get_datum_result($self->{datum_name});
    if(!(defined $result)) {
        croak("Datum '$self->{datum_name}' not defined for this observation: ". Dumper($observation));
    }
    $self->{result} |= $result;
    my $observation_time = $observation->get_time();

    if($self->{result} == 0){
        $self->set_start_time($observation_time);
    }
    if($result != 0) {
        $self->set_end_time($observation_time);
        $self->{end_threshold} = $observation_time->epoch() + $self->{timeout};
    }
    elsif($observation_time->epoch() > $self->{end_threshold}) {
        $self->{complete} = 1;
    }

    return $self->{result}; 
}

当我运行我的代码时，我收到以下警告:

Use of uninitialized value in numeric gt (>) at Performance/BadSpan.pm line 67 (#1)

第 67 行等于 if($result != 0) {线。

我的问题是双重的:

为什么 Perl 声明 $result未定义，当它前面有一些保护代码以确保它被定义时

当没有数字 gt 时，为什么 Perl 会提示数字 gt。与此警告相关的标题确实表明 Perl 可能会优化您的代码，并且该警告指的是优化的运算符，但这是否意味着 !=被“优化”为 >和一个 < ?

Answer 1

perl是什么版本?
给定的

use strict; use warnings;

my $x;

if ( $x ) {
    print "here\n";
}
elsif ( $x > 1 ) {
    print "there\n";
}

perl 5.10.1 正确输出: Use of uninitialized value $x in numeric gt (>) at C:\Temp\t.pl line 8.鉴于 elsif不是独立的，而是 if 的一部分声明，在早期版本中可能有一个错误报告了封闭 if 的行号。陈述。
This post和 this entry in perltodo 似乎相关:

eliminate incorrect line numbers in warnings

This code

  1. use warnings;
  2. my $undef;
  3.
  4. if ($undef == 3) {
  5. } elsif ($undef == 0) {
  6. }

used to produce this output:

  Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
  Use of uninitialized value in numeric eq (==) at wrong.pl line 4.

where the line of the second warning was misreported - it should be line 5. Rafael fixed this - the problem arose because there was no nextstate OP between the execution of the if and the elsif, hence PL_curcop still reports that the currently executing line is line 4. The solution was to inject a nextstate OPs for each elsif, although it turned out that the nextstate OP needed to be a nulled OP, rather than a live nextstate OP, else other line numbers became misreported. (Jenga!)

The problem is more general than elsif (although the elsif case is the most common and the most confusing). Ideally this code

   1. use warnings;
   2. my $undef;
   3.
   4. my $a = $undef + 1;
   5. my $b
   6. = $undef
   7. + 1;

would produce this output

   Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
   Use of uninitialized value $undef in addition (+) at wrong.pl line 7.

(rather than lines 4 and 5), but this would seem to require every OP to carry (at least) line number information.

What might work is to have an optional line number in memory just before the BASEOP structure, with a flag bit in the op to say whether it's present. Initially during compile every OP would carry its line number. Then add a late pass to the optimiser (potentially combined with repack the optree) which looks at the two ops on every edge of the graph of the execution path. If the line number changes, flags the destination OP with this information. Once all paths are traced, replace every op with the flag with a nextstate-light op (that just updates PL_curcop), which in turn then passes control on to the true op. All ops would then be replaced by variants that do not store the line number. (Which, logically, why it would work best in conjunction with repack the optree, as that is already copying/reallocating all the OPs)

(Although I should note that we're not certain that doing this for the general case is worth it)

这是实际的 commit .鉴于提交发生在 2008 年 4 月，我假设修复程序包含在 5.8.9 版本中(参见 perlhist)。