Returned value from subroutine is 1 when returning ""

[fidesachates]

I noticed a behavior that I can not explain. I would appreciate anyone who could provide an explanation and expand on the subject. I have noticed that when a sub routine returns a "", the value that get stored is not always "". When you throw in a || onto the end of the calling statement, the return value is 1.

#!/usr/bin/perl -w
use strict;

my $o = mysub() || print STDERR "didn't work\n";
print $o;
print "\n";

$o = mysub();
print $o;
print "\n";

sub mysub
{
        return "";
}

The first print will output a "1" while the second one will output the expect value of "". Can someone please explain why this occurs and any other symptoms like it? (E.g. If a different value gets returned depending on what the function after || is). Thanks.

[chromatic]

The empty string evaluates to false in a boolean context, so the first value stored in $o is the return value of the print.

[fidesachates]

Oh I understand now. I seem to have misunderstood the ||.

I read the code as (my $o = mysub()) || print ...

I see now that the grouping is my $o = (mysub() || print ...

Thank you.

[Fletch]

When in doubt about what exactly the precedence will be, B::Deparse is your friend.

$ perl -MO=Deparse,-b,-p -e 'my $o = mysub() || print STDERR "WHY U NO
+ WORK\n";' 
(my $o = (mysub() || print(STDERR "didnt work\n")));

[kennethk]

You are having an issue with Operator Precedence and Associativity. The || binds more tightly than the assignment operator, so you are assigning the return value of the print to $o. What you have is equivalent to

my $o = ( mysub() || print STDERR "didn't work\n" );

You can get your exected result either with explicit parentheses

(my $o = mysub() ) || print STDERR "didn't work\n";

or by swapping to the lower precedence or

my $o = mysub() or print STDERR "didn't work\n";

See Logical or, Defined or, and Exclusive Or in perlop.

[fidesachates]

Thanks for the links.

[mjscott2702]

You should use "or" instead of "||" here, since it has lower precedence - in fact, I believe(?) this is the recommended practice.

[DrHyde]

I recommend not using 'or', 'and' etc, but instead using brackets to make precedence explicit.

[sundialsvc4]

“Fair warning” here ...

I advise that you should not write code which depends on the “truth value” of whatever-it-is that a subroutine or expression might yield.   If you expect that a sub will return, say, “an empty string,” or “an integer 1 or 0,” or “undef” or what-have-you, test specifically for that.

And if you don't get anything you expect, (use Carp and) croak in a meaningful way.

“Put debugging tests into your program and leave them in until you’re absolutely sure that every last bug is gone.   Then, and only then ... leave them in.”

Sure, there are well-understood exceptions to that advice which we find everywhere in the language-of-use, such as the ... or die construct.   Such things are so well-known and widely accepted that they are probably just fine.   But the party that is always in the very best position to discover an error in a computer program is ... that computer program itself.   Within reason, the more that program(mer) takes the “I’m From Missouri... Show Me™” point of view, the more rugged and reliable his or her code turns out to be when it moves into production.