gibsonca has asked for the wisdom of the Perl Monks concerning the following question: 

Generally I can find and fix a problem like this. But 
this time it seems like something else is involved. The message, in 
the title of this post, appears from only line 123, and 
not on the previous lines. I do this same type of 'if' 
in other places with no messages. 

When I copy the code to a small test case, it works fine. I have 
verified with the debugger and print statements that the
variables involved are defined.

for ($sdd=0; $sdd <= $#gSDDdata; $sdd++) { # foreach SDD
  
  for ($srs=0; $srs <= $#gSRSData; $srs++) { # foreach SRS

    if (not defined $gSDDdata[$sdd]{source}) {
      print "m \n";
    }
    elsif (not defined ($gSRSData[$srs]{sect})) {
      print "n \n";
    }

    if ($gSDDdata[$sdd]{source} =~ /$gSRSData[$srs]{sect}/) { # <- 123

      $gSRSData[$srs]{found} = $gSDDdata[$sdd]{found} = 1;

    }
  }
}

[download]

Replies are listed 'Best First'.
Re: Use of unintialized value in pattern match (m//) at x.pl line 123
by linuxer (Curate) on May 14, 2009 at 21:51 UTC

    Please don't misuse the code tags.

    Use <p> tags in front of your text paragraphs, and keep the code tags for the real code sections. Thanks.

    Your line 123 is reached and executed whether $gSDDdata[$sdd]{source} and/or $gSRSData[$srs]{sect} are defined or not.

    Is that really what you want?

    Maybe you want to take some action where you print your "m" and "n" (e.g. continue with the next loop)?

    update: example added:

    #!/usr/bin/perl
use strict;
use warnings;

my @out = ( 1, undef, 3 );
my @in  = ( 4, 5, undef );

OUTER: 
for my $o ( @out ) {
  INNER: 
  for my $i ( @in ) {
    if ( !defined $o ) {
      next OUTER;
    }
    
    if ( !defined $i ) {
      next INNER;
    }

    printf "\$o(%d) * \$i(%d) = %d\n", $o, $i, $o * $i;
  }
}

    [download]

    update2: modified code;
[reply]
[d/l]
[select]

      I had modified my code to clearly? show myself that the variables were defined. I had no other reason why this particular 'if' statement would generate a message. The script does not fail, just generates this message. So the first if-else was just debug. The problem seems more related to the =~ compare, but again, never seen this message before on something that seemed to work in all other aspects/places. I don't want to say this, but it used to work. ;-)

[reply]
        
Problem solved.

The message identifies the problem at line 123, the beginning of an 
if-elsif-elsif-else piece of code. The problem 
occurred in a subsequent elsif branch, were a 
variable was mistyped by me. 
Live and learn.

        [download]
[reply]
[d/l]
Re: Use of unintialized value in pattern match (m//) at x.pl line 123
by graff (Chancellor) on May 15, 2009 at 21:17 UTC
    I gather your problem is solved, but I felt compelled to nit-pick about the OP code a little bit... Your use of the C-style for loop makes extra work for you, and your repeated testing of the "sdd" element inside the "srs" loop makes extra work for your cpu.

    Doing it this way would save you and your cpu some effort: 

    for my $sdd ( @gSDDdata ) {
    next unless ( ref( $sdd ) eq 'HASH' and $$sdd{source} );

    for my $srs ( @gSRSData ) {
        next unless ( ref( $srs ) eq 'HASH' and $$srs{sect} );

        $$srs{found} = $$sdd{found} = 1
            if ( $$sdd{source} =~ /$$srs{sect}/ );
    }
}

    [download]
    Also, it's usually a very minor point, but if there were a lot more "sdd" things than there are "srs" things, it would be better to have the larger number of things as the inner-most loop (other things being equal...)

    (Update: I thought about using ( ref( $sdd ) eq 'HASH' and defined( $$sdd{source} )) and likewise for srs, but since the crux of the process involves a regex match (which works on strings), I assumed you wouldn't be working on numerics (e.g. "0"), and you wouldn't want to set "found" = 1 in the case where $$srs{sect} was an empty string and $$sdd{source} could be anything at all. But it's up to you to decide how much to trust the data.)

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom