http://www.perlmonks.org?node_id=1063106


in reply to Unexpected warning

You get that warning on that line if $something is undefined. Although in that case you also ought to get another warning as well, about using an uninitialized value in a hash element on the calling line.

Replies are listed 'Best First'.
Re^2: Unexpected warning
by LanX (Saint) on Nov 18, 2013 at 15:00 UTC
    > You get that warning on that line if $something is undefined.

    yep I can reproduce this. =)

    Seems like in the context of the call warnings were disabled.

    DB<132> use warnings; sub tst {my $a=shift, my $b =shift} DB<133> %h=() DB<134> $bla="" => "" DB<135> tst $h{$bla} => (undef, undef) DB<136> undef $bla => undef DB<137> tst $h{$bla} Use of uninitialized value in scalar assignment at (eval 81)[multi_per +l5db.pl:644] line 2.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

      I can reproduce it myself too now:
      tst(undef); # doesn't warn from tst tst($foo{undef}); # doesn't warn from tst tst($foo{$undef}); # warns from tst
      I would say this is a bug in perl, or I am missing something?

        The undef value is subtly different from using an undefined variable, so that may be causing the problem.

        tst($foo{undef});  # doesn't warn from tst

        This uses the undef value as a key into the %foo hash; the key presumably doesn't exist so Perl returns undef. This is working as I would expect.

        tst($foo{$undef});  # warns from tst

        This looks up the value of $undef, which presumably isn't defined, so Perl should flag an error at that statement, not inside tst. If that is the case, then it, too, is working as I would expect.

      I get no warnings from the code below:

      use strict; use warnings; sub test { my $x = shift; } my %hash = ( a => "a" ); test $hash{"b"};
        The key must be undef.

        lanx@nc10-ubuntu:~$ perl use strict; { use warnings; sub test { my $x = shift; } } my %hash = ( a => "a" ); my $key; test $hash{$key} Use of uninitialized value in scalar assignment at - line 3. lanx@nc10-ubuntu:~$ perl -version This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

        I agree with salva that this is kind of a bug in lexical warnings.

        Cheers Rolf

        ( addicted to the Perl Programming Language)

Re^2: Unexpected warning
by samwyse (Scribe) on Nov 18, 2013 at 17:11 UTC
    This should be pretty definitive...
    use strict; use warnings; sub tst { warn "entering tst()\n"; my $arg = shift; # line 6 warn "leaving tst()\n\n"; } my %h=(); tst $h{''}; tst $h{undef}; # line 12 my $bla=''; tst $h{$bla}; # line 14 $bla=undef; tst $h{$bla}; # line 16 undef $bla; tst $h{$bla}; # line 19
    And here's the results:
    entering tst() leaving tst() entering tst() leaving tst() entering tst() leaving tst() Use of uninitialized value $bla in hash element at perlmonks-1063097.p +l line 16. entering tst() Use of uninitialized value in scalar assignment at perlmonks-1063097.p +l line 6. leaving tst() Use of uninitialized value $bla in hash element at perlmonks-1063097.p +l line 18. entering tst() Use of uninitialized value in scalar assignment at perlmonks-1063097.p +l line 6. leaving tst()

    Turning off 'strict' has no effect, while turning off 'warnings' warnings gets rid of the messages.

    I'm actually surprised by a couple of aspects of this. First, I expected $bla=undef; tst $h{$bla} to behave the same as tst $h{undef}; it didn't. Instead, $bla=undef seems to have the same effect as undef $bla. Second, it seems that lines 16 and 19 are generating a value other than a simple undef to pass into the subroutine, otherwise the invocation in line 12 would have also generated an error in line 6.

Re^2: Unexpected warning
by hdb (Monsignor) on Nov 18, 2013 at 15:01 UTC

    I get no warnings from this code below:

    use strict; use warnings; my @array; my $x = shift @array; my $y = shift @array;