From wolf-dietrich_moeller@t-online.de

The documentation on assignments in perlop reads:
"a list assignment in list context produces the
list of lvalues assigned to"

The following program shows a regression,
when the "list assigned to" contains "undef".
(tested with two old versions available to me:

• Strawberry Perl Portable 5.22.3.1-32bit
• Strawberry Perl Portable 5.26.2.1-32bit)

The newer version 5.26 (and also 5.28) works correctly if the
third element in the list assigned to is a variable (test 3),
but ignores the third element if it is undef.
Thus @s in test 4 only has 2 elements instead of 3.

my ($y, @s);
my $x = 5;
print 'test 1: ',scalar (@s = (($y) = (8,9))),' ',$y,' ',$x//'undef',"\n";
my $x = 5;
print 'test 2: ',scalar (@s = (($y,undef) = (8,9))),' ',$y,'
',$x//'undef',"\n";
my $x = 5;
print 'test 3: ',scalar (@s = (($y,undef,$x) = (8,9))),' ',$y,'
',$x//'undef',"\n";
my $x = 5;
print 'test 4: ',scalar (@s = (($y,undef,undef) = (8,9))),' ',$y,'
',$x//'undef',"\n";

Result in 5.22 (correct, @s == 3):
test 1: 1 8 5
test 2: 2 8 5
test 3: 3 8 undef
test 4: 3 8 5

Result in 5.26 (test 4 incorrect, @s == 2):
test 1: 1 8 5
test 2: 2 8 5
test 3: 3 8 undef
test 4: 2 8 5

From @iabyn

On Fri, Sep 07, 2018 at 08​:48​:29AM -0700, Wolf-Dietrich Moeller (via RT) wrote​:

The documentation on assignments in perlop reads​:
"a list assignment in list context produces the
list of lvalues assigned to"

The following program shows a regression,
when the "list assigned to" contains "undef".
(tested with two old versions available to me​:
- Strawberry Perl Portable 5.22.3.1-32bit
- Strawberry Perl Portable 5.26.2.1-32bit)

The newer version 5.26 (and also 5.28) works correctly if the
third element in the list assigned to is a variable (test 3),
but ignores the third element if it is undef.
Thus @​s in test 4 only has 2 elements instead of 3.

Bisects to this. I haven't looked further yet.

commit b09ed99
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Wed Oct 19 09​:41​:53 2016 +0100
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Wed Oct 26 08​:37​:27 2016 +0100

  Handle list assignment in list context better
 
  In something like
 
  sub inc { $_++ for @​_ }
  inc(($a,$b,$c,$d) = (10,20))
 
  The four scalar vars will end up with the values (11,21,1,1), with
  the list assign op returning 4 lval scalars to be passed to inc.
 
  However, when the LHS includes a hash or array, any 'empty' scalars weren't
  being returned. This​:
 
  inc(($a,$b,@​array,$c) = (10))
 
  used to leave $b and $c undefined. With this commit, they are both set to
  1.
 
  This change broke some tests in hashassign.t, which were added in 2012
  by commit v5.17.6-295-gb1babc5. Half these tests were commented as
 
  # this arguable, but this is how it works
 
  and they all tested that a scalar following a hash wasn't returned in
  lvalue context; i.e. they all assumed that
 
  inc((%h, $x) = (...))
 
  *wouldn't* increment $x. This commit causes $x to be incremented, and
  I've changed the failing tests.
 
  It also adds an EXTEND(SP,1) in the scalar case; otherwise with
  scalar( () = @​a) and empty @​a, it could in theory push the '0' return
  value off the end of the stack.

--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
  -- Things That Never Happen in "Star Trek" #19

The RT System itself - Status changed from 'new' to 'open'

This is unchanged in 5.30

Now fixed in blead by commit v5.33.0-236-g282d9dfeb4