From luke@daeron.com

Here is some code illustrating the bug​:

sub foo {('a','b')}
@​foo{qw(foo bar)} =(foo())[1,-1];
print "$foo{bar}\n";

<<<

this should print "b\n" but doesn't. it's a once-in-a-blue-moon kind of thing;
almost any other way of doing the same thing works correctly. it has to
be an array slice of a function call assigned to a hash slice, the list has
to be two elements, and you need to use -1 as an element of the array slice.
in fact, if the '1' above is changed to '0', it works correctly.

[SoSiouxMe] --> perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=linux, osvers=2.2.1-ac1, archname=i386-linux
  uname='linux porky.devel.redhat.com 2.2.1-ac1 #1 smp mon feb 1 17​:44​:44 est 1999 i686 unknown '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
  cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
  ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
  stdchar='char', d_stdstdio=undef, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib
  libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
  libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
  cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl)​:
  Built under linux
  Compiled at Apr 6 1999 23​:34​:07
  @​INC​:
  /usr/lib/perl5/5.00503/i386-linux
  /usr/lib/perl5/5.00503
  /usr/lib/perl5/site_perl/5.005/i386-linux
  /usr/lib/perl5/site_perl/5.005
  .

From [Unknown Contact. See original ticket]

On Sat, 12 Feb 2000 13​:59​:52 -0600 (CST), Luke Meyer wrote (in part)​:

Luke> sub foo {('a','b')}
Luke> @​foo{qw(foo bar)} =(foo())[1,-1];
Luke> print "$foo{bar}\n";

Luke> it has to be an array slice of a function call assigned to
Luke> a hash slice,

Almost true, and this is really most of it.

The rest of the claims aren't strictly required. Change the '-1'
above to '1' and it fails the same way. The problem is that the
function return of a list gets transmogrified into a list of
temps in leavesub, but the slice doesn't care that it gets the
*same* temp sv on the stack twice. The aasign op then consumes
the temp by 'stealing' from it, and then has the now-empty temp
for the next assignment in its loop. Oops.

I'm not sure whether the right answer here so to have the lslice
op notice when it puts a temp on the stack twice, and to clone it
if so, or whether the aassign should avoid temp-stealing on its
embedded assignments. Either way, I suspect that if I worked at
it I could find some other way that temp-stealing breaks a
reasonable assumption. I'm starting to think that it might not
have been such a great optimisation after all.

--
Spider Boardman (at home) spider@​Orb.Nashua.NH.US
The management (my cats) made me say this. http​://www.ultranet.com/~spiderb
PGP public key fingerprint​: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC

From @iabyn

was fixed (aparently) by patch 7867 in 5.8.0

@iabyn - Status changed from 'open' to 'resolved'