Skip Menu |
Report information
Id: 93102
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: sprout <sprout [at] cpan.org>
Cc:
AdminCc:

Operating System: darwin
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.14.0
Fixed In: (no value)



Subject: keys is not always an lvalue
Date: Sun, 19 Jun 2011 19:23:58 -0700
To: perlbug [...] perl.org
From: Father Chrysostomos <sprout [...] cpan.org>
Download (untitled) / with headers
text/plain 2.8k
$ 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: eb70bb4a400e88a66c7e10414a2d52b5da4cfd1f 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
CC: bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #93102] keys is not always an lvalue
Date: Mon, 20 Jun 2011 00:36:37 -0400
To: perl5-porters [...] perl.org
From: Eric Brine <ikegami [...] adaelis.com>
On Sun, Jun 19, 2011 at 10:24 PM, Father Chrysostomos < perlbug-followup@perl.org> wrote: Show quoted text
> # 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. Show quoted text
> 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
CC: bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #93102] keys is not always an lvalue
Date: Mon, 20 Jun 2011 01:02:43 -0400
To: perl5-porters [...] perl.org
From: Eric Brine <ikegami [...] adaelis.com>
On Sun, Jun 19, 2011 at 10:24 PM, Father Chrysostomos < perlbug-followup@perl.org> wrote: Show quoted text
> # 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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Sun Jun 19 21:37:15 2011, ikegami@adaelis.com wrote: Show quoted text
> 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....
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Sun Jun 19 22:03:13 2011, ikegami@adaelis.com wrote: Show quoted text
> 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.
RT-Send-CC: perl5-porters [...] perl.org, ikegami [...] adaelis.com
Download (untitled) / with headers
text/plain 250b
On Sun Jun 19 22:03:13 2011, ikegami@adaelis.com wrote: Show quoted text
> 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?
Date: Sat, 4 Nov 2017 23:26:18 +0000
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #93102] keys is not always an lvalue
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 114b
This was fixed by commit e4fc70828d25802f8f511e75d50813489648c124 in 5.27.2. This ticket can be closed. -zefram


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org