[perl #93102] keys is not always an lvalue

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.

• [perl #93102] keys is not always an lvalue by Father Chrysostomos via RT
• [perl #93102] keys is not always an lvalue by Father Chrysostomos via RT