From mjtg@cus.cam.ac.uk

  perl -wle '(@​a = (1,2,3)) = (4,5);print @​a'
  Use of uninitialized value at -e line 1.
  45

Where's that undef coming from ?

And I can't find any documentation of the result of a list assignment in
a list context. Is it meant to be the list of lvalues assigned to?

Mike Guy

% perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=sunos, osvers=4.1.3, archname=sun4-sunos
  uname=''
  hint=previous, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='gcc', optimize='-O', gccversion=2.7.2.3
  cppflags='-I/usr/local/include -DREG_INFTY=22790'
  ccflags ='-I/usr/local/include -DREG_INFTY=22790'
  stdchar='unsigned char', d_stdstdio=define, usevfork=true
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='ld', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /usr/ucblib
  libs=-ldbm -ldl -lm -lc -lposix
  libc=/lib/libc.so.1.8, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-fpic', lddlflags='-assert nodefinitions -L/usr/local/lib'

Characteristics of this binary (from libperl)​:
  Locally applied patches​:
  pos.list
  IO.file.return
  int.delimiter
  bigfloat
  Built under sunos
  Compiled at Jul 7 1999 16​:09​:54
  @​INC​:
  /home/mjtg/perl5.005_03/lib
  /home/mjtg/perl5.005_03/lib
  /home/mjtg/perl5.005_03/lib
  .

From @tamias

On Tue, Oct 12, 1999 at 05​:39​:03PM +0100, M.J.T. Guy wrote​:

Assigning to a list assignment seems to do strange things​:

      perl \-wle '\(@​a = \(1\,2\,3\)\) = \(4\,5\);print @​a'
      Use of uninitialized value at \-e line 1\.
      45

Where's that undef coming from ?

And I can't find any documentation of the result of a list assignment in
a list context. Is it meant to be the list of lvalues assigned to?

Intriguing! Basically, you're assigning a list of two elements to a list
of three elements, so you end up with the third element being undef.

Compare to​:

@​a[0,1,2] = (4,5);

Whether this is the desired behavior or not, I couldn't say! :)

Ronald

From [Unknown Contact. See original ticket]

ts <decoux@​moulon.inra.fr> wrote to me privately

"M" == M J T Guy <mjtg@​cus.cam.ac.uk> writes​:
M> Where's that undef coming from ?
Apparently $a[2], try it with print @​a[0, 1]

Duh! Of course it is. So the bug report can be closed
"Pilot error". And all that needs doing is to patch the
documentation. (Patch is for 5.005_03 FWIW)

Mike Guy

--- ./pod/perlop.pod.orig	Sun Mar 28 00:04:48 1999
+++ ./pod/perlop.pod	Wed Oct 13 04:18:25 1999
@@ -501,9 +501,9 @@
 Note that while these are grouped by family, they all have the precedence
 of assignment.
 
-Unlike in C, the assignment operator produces a valid lvalue.  Modifying
-an assignment is equivalent to doing the assignment and then modifying
-the variable that was assigned to.  This is useful for modifying
+Unlike in C, the (scalar) assignment operator produces a valid lvalue.
+Modifying an assignment is equivalent to doing the assignment and then
+modifying the variable that was assigned to.  This is useful for modifying
 a copy of something, like this:
 
     ($tmp = $global) =~ tr [A-Z] [a-z];
@@ -516,6 +516,11 @@
 
     $a += 2;
     $a *= 3;
+
+Similarly, a list assigment in list context produces the list of
+lvalues assigned to.  But list assignment in a scalar context returns
+the number of elements produced by the expression on the right side of
+the assignment.
 
 =head2 Comma Operator
 

End of patch