Bad return value from a block with variable localization

[jesuashok]

Hello all,

I've run into this strange behaviour when playing with trying to make functions return different values from the number of parameters they were called with. If you test @_, and that you return from a do { ... } block where a variable is localized, the return value is undef if you don't add an else statement.

#!/usr/bin/perl -w

use strict;

sub foo {
  if (@_) {
    return do { my $dummy; 1; };
   } else {
    return 0;
  }
}

# let's just remove the else

sub bar {
  if (@_) {
     return do { my $dummy; 1; };
  }
  return 0;
}

print foo().' '.foo('baz')."\n"; # that was expected
print bar().' '.bar('baz')."\n"; # undef

##################################################
Expected output:

0 1
0 1

##################################################
Actual output:

0 1
Use of uninitialized value in concatenation (.) or string at ./undef.p
+l line 24.
0

##################################################

2006-10-07 Unapproved by planetscape once evidence of habitual plagiarism uncovered.

[BrowserUk]

As a temporary workaround until the bug is fixed, the following seems to 'cure' it and I can't see any other side effects:

sub bar {
  if (@_) {
     return my $x = do { my $dummy; 1; };
  }
  return 0;
}

[codeacrobat]

It also helps to actually "return 1;" instead of just "1;" In general use the short form only when you are really at the end of a subroutine. do blocks are not really subroutines.

#!/usr/bin/perl

use strict;
use warnings;

# let's just remove the else

sub foo {
    if (@_) {
        return do { my $dummy; return 1; };
    }
    0;
}

sub bar {
    if (@_) {
        return do { my $dummy; return 1; };
    } else {
    0;
    }
}

print foo() . ' ' . foo('baz') . "\n";    # 1 0
print bar() . ' ' . bar('baz') . "\n";    # also 1 0

Update:
I noticed that the above script is bad style for a direct return from the subroutine. You should use eval instead of do. See the example below.

 #!/usr/bin/perl

 use strict;
 use warnings;

 # let's just remove the else

 sub foo {
     if (@_) {
         return 10 + do { my $dummy; return 1; };
     }
     0;
 }

 sub bar {
     if (@_) {
         return 10 + eval { my $dummy; return 1; };
     }
     0;
 }

 print foo() . ' ' . foo('baz') . "\n";    # 1 0
 print bar() . ' ' . bar('baz') . "\n";    # 11 0

[liverpole]

From this site, first posted on March 28, 2006:

[Please enter your report here]

Hello,

I've run into this strange behaviour when playing with trying
to make functions return different values from the number of
parameters they were called with. If you test [at]_, and that you
return from a do { ... } block where a variable is localized,
the return value is undef if you don't add an else statement.

Looks like some parsing bug, but not that I'm good enough to have
any real clue about it.

Regards,

Vincent Pit

#################################################################
Test case: (line 1 is #!)

#!/usr/bin/perl

use strict;
use warnings;

sub foo {
 if (@_) {
  return do { my $dummy; 1; };
 } else {
  return 0;
 }
}

# let's just remove the else

sub bar {
 if (@_) {
  return do { my $dummy; 1; };
 }
 return 0;
}

print foo().' '.foo('baz')."\n"; # that was expected
print bar().' '.bar('baz')."\n"; # undef

#################################################################
Expected output:

0 1
0 1

#################################################################
Actual output:

0 1
Use of uninitialized value in concatenation (.) or string at ./bug.pl 
+line 24.
0

#################################################################

[jdporter]

And for that, he got 56+ upvotes? :-(

I propose a moratorium on approving any post by that plagiarist, who without a doubt doesn't actually know one bit of Perl.

[liverpole]

I think that's a very good idea.

By the way, I discovered this afternoon that [id://madtoperl|another plagiarist] has a similar lack of ethics here, which I've pointed out in the thread which starts here.

Like jesuashok, madtoperl has been confronted for this illegal behavior numerous times, as I'm sure you're aware.

If indeed they are the same person, perhaps it's time to ask [id://gods|the gods] for help in tracking their IP address, so that we can put a stop to it.