Perl variable initialization bug using in a subroutine

Question

So I have a situation where I have a function with two named arguments, but if both are used the function needs to die. I'm not sure if this is a bug, or if there's something intrinsic I'm not understanding about Perl variables.

Here's the simplified code:

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper;

foreach my $number (1..5)
{
    fooBar(foo => $number);
}

sub fooBar 
{
    my %args = (
        foo => undef,
        bar => undef,
        @_
    );

    my $foo = $args{foo} if defined $args{foo};
    my @bar = @{$args{bar}} if defined $args{bar};
    print Dumper(\@bar);

    if (defined $foo)
    {
        die('fooBar() received both a foo and a bar and didn\'t know which to use!') if @bar;
        push(@bar, $foo);
    }

    print Dumper(\@bar);
    return (\@bar);
}

# > $VAR1 = [];
# > $VAR1 = [
# >           1
# >         ];
# > $VAR1 = [
# >           1
# >         ];
# > fooBar() received both a foo and a bar and didn't know which to use! at ./example.pl line 27.

Here's my solution:

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper;

foreach my $number (1..5)
{
    fooBar(foo => $number);
}

sub fooBar 
{
    my %args = (
        foo => undef,
        bar => undef,
        @_
    );

    my $foo;
    my @bar;
    $foo = $args{foo} if defined $args{foo};
    @bar = @{$args{bar}} if defined $args{bar};
    print Dumper(\@bar);

    if (defined $foo)
    {
        die('fooBar() received both a foo and a bar and didn\'t know which to use!') if @bar;
        push(@bar, $foo);
    }

    print Dumper(\@bar);
    return (\@bar);
}

# > $VAR1 = [];
# > $VAR1 = [
# >           1
# >         ];
# > $VAR1 = [];
# > $VAR1 = [
# >           2
# >         ];
# > $VAR1 = [];
# > $VAR1 = [
# >           3
# >         ];
# > $VAR1 = [];
# > $VAR1 = [
# >           4
# >         ];
# > $VAR1 = [];
# > $VAR1 = [
# >           5
# >         ];

My question is, why does this fix the problem? In the first example, the first time fooBar() is called, @bar is getting initialized despite failing the if condition. The second time through the loop, @bar has somehow retained its information from the first loop, yet it doesn't complain about being reinitialized. It seems to me that either a) @bar should be wiped after the subroutine finishes (which is what I was expecting), b) @bar shouldn't be initialized after it fails the if defined test, or c) @bar should complain that it's being reinitialized the second time through the loop. I'm pretty confused here, is this just a bug?

ah, you try to find bug in Perl? do you really understand what Perl understand in your code?;) I think that assignment inside lazy if-clause (do{my $var = value;}if value); should cause a problem — gaussblurinc
– gaussblurinc, Commented Aug 15, 2014 at 18:07
just don't do my ... if. but what actually happens (currently; it is flagged in the doc as subject to change) is that my has both a compile-time an a run time effect; the if can skip the run time effect, keeping perl from knowing it needs to reinitializing the variable at end of scope. — ysth
– ysth, Commented Aug 15, 2014 at 18:15
in such cases, try perlcritic too: it says: Variable declared in conditional statement at line 22, column 5. Declare variables outside of the condition. (Severity: 5) (and the same for the line 23) — clt60
– clt60, Commented Aug 15, 2014 at 18:22

ysth · Accepted Answer · 2014-08-15 18:09:24Z

7

This only conditionally creates a new variable, and can lead to strange to understand results:

my $foo = $args{foo} if defined $args{foo};

perldoc perlsyn has this to say:

NOTE: The behaviour of a my, state, or our modified with a statement modifier conditional or loop construct (for example, my $x if ... ) is undefined. The value of the my variable may be undef, any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.

Don't try to define a $foo variable; just use $args{foo}. Or just do the assignment unconditionally; there's nothing wrong with assigning undef.

answered Aug 15, 2014 at 18:09

ysth

99.1k6 gold badges126 silver badges219 bronze badges

Sign up to request clarification or add additional context in comments.

5 Comments

Jason Hamje Over a year ago

Very interesting. I had other reasons for formatting the code this way that aren't apparent in my example, although looking over it I'm... not sure what those reasons were anymore. Perhaps I'll get rid of it and see what breaks. Thanks for your reply :)

gaussblurinc Over a year ago

@JasonHamje, documentation ... you know what you should do ;)

Chris Doyle Over a year ago

@ysth I think he was making the point to Jason about why its good to document your own code. Since Jason said he had other reasons for formatting his code but cannot remember them. If he had documented them then he wouldnt have to remember.

Jason Hamje Over a year ago

@gaussblurinc; fair enough, fair enough :P

gaussblurinc Over a year ago

@ysth, uh, english sarcasm so simple.. uh, no, I mean that OP should read it in future

Collectives™ on Stack Overflow

Perl variable initialization bug using in a subroutine

1 Answer 1

5 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

5 Comments

Your Answer

Sign up or log in

Post as a guest

Related