From @cpansprout

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if Perl had *some* consistency.

I believe that *deleting* some code in op.c would make this work without breaking anything else. (In op_lvalue, the initial if() condition under case OP_KEYS.)

Flags​:
  category=core
  severity=low

Site configuration information for perl 5.14.0​:

Configured by sprout at Wed May 11 13​:45​:58 PDT 2011.

Summary of my perl5 (revision 5 version 14 subversion 0) configuration​:
  Snapshot of​: eb70bb4
  Platform​:
  osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0​: fri nov 5 23​:20​:39 pdt 2010; root​:xnu-1504.9.17~1release_i386 i386 '
  config_args='-Dusedevel -de -Duseithreads -Doptimize=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-g',
  cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches​:
  RC3

@​INC for perl 5.14.0​:
  /usr/local/lib/perl5/site_perl/5.14.0/darwin-thread-multi-2level
  /usr/local/lib/perl5/site_perl/5.14.0
  /usr/local/lib/perl5/5.14.0/darwin-thread-multi-2level
  /usr/local/lib/perl5/5.14.0
  /usr/local/lib/perl5/site_perl
  .

Environment for perl 5.14.0​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

From @ikegami

On Sun, Jun 19, 2011 at 10​:24 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Father Chrysostomos
# Please include the string​: [perl #93102]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=93102 >

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if Perl had
*some* consistency.

Maybe it was there to try to avoid problems when lvalue keys used TARG.
Since lvalue keys now returns a fresh scalar, there's no problem having two
keys lvalues in existance, so the lifespan of the lvalue can be expanded
safely.

I believe that *deleting* some code in op.c would make this work without
breaking anything else. (In op_lvalue, the initial if() condition under case
OP_KEYS.)

I notice that pos() and vec() don't have this limitation. Go ahead, I'd say.

- Eric

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

From @ikegami

On Sun, Jun 19, 2011 at 10​:24 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Father Chrysostomos# Please include the string​:
[perl #93102]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=93102 >

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if Perl had
*some* consistency.

I believe that *deleting* some code in op.c would make this work without
breaking anything else. (In op_lvalue, the initial if() condition under case
OP_KEYS.)

While you're at it, consider

pad_free(o->op_targ);
o->op_targ = pad_alloc(o->op_type, SVs_PADMY);
assert(SvTYPE(PAD_SV(o->op_targ)) == SVt_NULL);

I'm thinking that can be replaced with

pad_free(o->op_targ);
o->op_targ = 0;

since none of the five ops use TARG when called in lvalue context anymore.

From @cpansprout

On Sun Jun 19 21​:37​:15 2011, ikegami@​adaelis.com wrote​:

On Sun, Jun 19, 2011 at 10​:24 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Father Chrysostomos
# Please include the string​: [perl #93102]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=93102 >

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if
Perl had
*some* consistency.

Maybe it was there to try to avoid problems when lvalue keys used
TARG.
Since lvalue keys now returns a fresh scalar, there's no problem
having two
keys lvalues in existance, so the lifespan of the lvalue can be
expanded
safely.

I believe that *deleting* some code in op.c would make this work
without
breaking anything else. (In op_lvalue, the initial if() condition
under case
OP_KEYS.)

I notice that pos() and vec() don't have this limitation. Go ahead,
I'd say.

Actually, it would allow keys() assignment in list context, causing this
to be a no-op on empty hashes​:

(keys %x) = 42;

So I need to think about this more....

From [Unknown Contact. See original ticket]

On Sun Jun 19 21​:37​:15 2011, ikegami@​adaelis.com wrote​:

On Sun, Jun 19, 2011 at 10​:24 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Father Chrysostomos
# Please include the string​: [perl #93102]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=93102 >

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if
Perl had
*some* consistency.

Maybe it was there to try to avoid problems when lvalue keys used
TARG.
Since lvalue keys now returns a fresh scalar, there's no problem
having two
keys lvalues in existance, so the lifespan of the lvalue can be
expanded
safely.

I believe that *deleting* some code in op.c would make this work
without
breaking anything else. (In op_lvalue, the initial if() condition
under case
OP_KEYS.)

I notice that pos() and vec() don't have this limitation. Go ahead,
I'd say.

Actually, it would allow keys() assignment in list context, causing this
to be a no-op on empty hashes​:

(keys %x) = 42;

So I need to think about this more....

From @cpansprout

On Sun Jun 19 22​:03​:13 2011, ikegami@​adaelis.com wrote​:

On Sun, Jun 19, 2011 at 10​:24 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Father Chrysostomos# Please include the
string​:
[perl #93102]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=93102 >

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if
Perl had
*some* consistency.

I believe that *deleting* some code in op.c would make this work
without
breaking anything else. (In op_lvalue, the initial if() condition
under case
OP_KEYS.)

While you're at it, consider

pad_free(o->op_targ);
o->op_targ = pad_alloc(o->op_type, SVs_PADMY);
assert(SvTYPE(PAD_SV(o->op_targ)) == SVt_NULL);

I'm thinking that can be replaced with

pad_free(o->op_targ);
o->op_targ = 0;

since none of the five ops use TARG when called in lvalue context
anymore.

But this code path (op_lvalue) is reached not only for true lvalue
context, but also for reference (potential lvalue) context, such as
arguments to a subroutine.

From [Unknown Contact. See original ticket]

On Sun Jun 19 22​:03​:13 2011, ikegami@​adaelis.com wrote​:

On Sun, Jun 19, 2011 at 10​:24 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Father Chrysostomos# Please include the
string​:
[perl #93102]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=93102 >

$ perl -le 'read foo, keys %foo, $foo'
Can't modify keys in read at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Why would you want to do that? You wouldn’t, but it would nice if
Perl had
*some* consistency.

I believe that *deleting* some code in op.c would make this work
without
breaking anything else. (In op_lvalue, the initial if() condition
under case
OP_KEYS.)

While you're at it, consider

pad_free(o->op_targ);
o->op_targ = pad_alloc(o->op_type, SVs_PADMY);
assert(SvTYPE(PAD_SV(o->op_targ)) == SVt_NULL);

I'm thinking that can be replaced with

pad_free(o->op_targ);
o->op_targ = 0;

since none of the five ops use TARG when called in lvalue context
anymore.

But this code path (op_lvalue) is reached not only for true lvalue
context, but also for reference (potential lvalue) context, such as
arguments to a subroutine.

From @cpansprout

On Sun Jun 19 22​:03​:13 2011, ikegami@​adaelis.com wrote​:

While you're at it, consider

pad_free(o->op_targ);
o->op_targ = pad_alloc(o->op_type, SVs_PADMY);

What exactly do those two lines do anyway? What is in op_targ that needs
to be freed?

From [Unknown Contact. See original ticket]

On Sun Jun 19 22​:03​:13 2011, ikegami@​adaelis.com wrote​:

While you're at it, consider

pad_free(o->op_targ);
o->op_targ = pad_alloc(o->op_type, SVs_PADMY);

What exactly do those two lines do anyway? What is in op_targ that needs
to be freed?

From zefram@fysh.org

This was fixed by commit e4fc708
in 5.27.2. This ticket can be closed.

-zefram

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