all XS functions are implicitly :lvalue #12955

p5pRT · 2013-05-10T15:59:39Z

Migrated from rt.perl.org#117947 (status was 'resolved')

Searchable as RT117947$

p5pRT · 2013-05-10T15:59:39Z

From @mauke

Created by @mauke

The following problem was found by yko (Yaroslav Korshak):

% perl -wle 'use List::Util qw(maxstr); List::Util->maxstr($_ = "hi") = 42; print'
42

% ./perl -v
This is perl 5, version 17, subversion 11 (v5.17.11 (v5.17.10-74-g4702594*)) built for i686-linux
...

% ./perl -Ilib -wle 'use List::Util qw(maxstr); List::Util->maxstr($_ = "hi") = 42; print'
42

Apparently starting with version 16 perl thinks that all XS functions return lvalues.

For comparison, the expected result (here with 5.12.4):
$ perl -wle 'use List::Util qw(maxstr); print List::Util->maxstr("hi") = 42; print'
Can't modify non-lvalue subroutine call at -e line 1.

Perl Info


Flags:
    category=core
    severity=medium

This perlbug was built using Perl 5.12.1 - Thu Jun  3 20:09:15 CEST 2010
It is being executed now by  Perl 5.16.3 - Sun Mar 24 20:23:51 CET 2013.

Site configuration information for perl 5.16.3:

Configured by mauke at Sun Mar 24 20:23:51 CET 2013.

Summary of my perl5 (revision 5 version 16 subversion 3) configuration:
   
  Platform:
    osname=linux, osvers=3.5.7-gentoo, archname=i686-linux
    uname='linux nora 3.5.7-gentoo #5 preempt sat jan 26 16:46:10 cet 2013 i686 amd athlon(tm) 64 processor 3200+ authenticamd gnulinux '
    config_args=''
    hint=previous, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -flto',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    ccversion='', gccversion='4.8.0', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-fstack-protector -L/usr/local/lib -O2 -flto'
    libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.15.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.15'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -flto -L/usr/local/lib -fstack-protector'

Locally applied patches:
    SAVEARGV0 - disable magic open in <ARGV>


@INC for perl 5.16.3:
    /home/mauke/usr/local/lib/perl5/site_perl/5.16.3/i686-linux
    /home/mauke/usr/local/lib/perl5/site_perl/5.16.3
    /home/mauke/usr/local/lib/perl5/5.16.3/i686-linux
    /home/mauke/usr/local/lib/perl5/5.16.3
    /home/mauke/usr/local/lib/perl5/site_perl/5.16.0/i686-linux
    /home/mauke/usr/local/lib/perl5/site_perl/5.16.0
    /home/mauke/usr/local/lib/perl5/site_perl
    .


Environment for perl 5.16.3:
    HOME=/home/mauke
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=POSIX
    LD_LIBRARY_PATH=/home/mauke/usr/local/lib
    LOGDIR (unset)
    PATH=/home/mauke/usr/perlbrew/bin:/home/mauke/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.6.3:/opt/sun-jdk-1.4.2.13/bin:/opt/sun-jdk-1.4.2.13/jre/bin:/opt/sun-jdk-1.4.2.13/jre/javaws:/opt/dmd/bin:/usr/games/bin
    PERLBREW_BASHRC_VERSION=0.43
    PERLBREW_HOME=/home/mauke/.perlbrew
    PERLBREW_PATH=/home/mauke/usr/perlbrew/bin
    PERLBREW_ROOT=/home/mauke/usr/perlbrew
    PERLBREW_VERSION=0.27
    PERL_BADLANG (unset)
    PERL_UNICODE=SAL
    SHELL=/bin/bash

p5pRT · 2013-05-13T11:29:01Z

From @rgarcia

On 10 May 2013 17:59, l.mai@web.de <perlbug-followup@perl.org> wrote:

The following problem was found by yko (Yaroslav Korshak):

% perl -wle 'use List::Util qw(maxstr); List::Util->maxstr($_ = "hi") = 42; print'
42

maxstr is not a method; if you use List::Util::maxstr() instead, it
complains as it should:

~§ perl -wle 'use List::Util qw(maxstr); List::Util::maxstr($_ = "hi")
= 42; print'
Can't modify non-lvalue subroutine call in scalar assignment at -e
line 1, near "42;"
Execution of -e aborted due to compilation errors.

That said, we actually seem to have a problem with XS functions called
as methods.

p5pRT · 2013-05-13T11:29:02Z

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

p5pRT · 2013-05-13T12:13:10Z

From @Leont

On Mon, May 13, 2013 at 1:28 PM, Rafael Garcia-Suarez <rgs@consttype.org> wrote:

maxstr is not a method; if you use List::Util::maxstr() instead, it
complains as it should:

~§ perl -wle 'use List::Util qw(maxstr); List::Util::maxstr($_ = "hi")
= 42; print'
Can't modify non-lvalue subroutine call in scalar assignment at -e
line 1, near "42;"
Execution of -e aborted due to compilation errors.

That said, we actually seem to have a problem with XS functions called
as methods.

Yeah, the keywords there seems to be "compilation errors". For methods
we have to detect this at runtime…

Leon

p5pRT · 2013-05-13T13:46:15Z

From @mauke

I ran bisect.pl and it ended with:

da1dff9 is the first bad commit
commit da1dff9
Author: Father Chrysostomos <sprout@cpan.org>
Date: Mon Dec 26 13:25:31 2011 -0800

Fix two (er, four) sub:lvalue { &$x } bugs

...

p5pRT · 2013-05-13T19:18:21Z

From @mauke

On 13.05.2013 14:12, Leon Timmermans wrote:

On Mon, May 13, 2013 at 1:28 PM, Rafael Garcia-Suarez <rgs@consttype.org> wrote:

maxstr is not a method; if you use List::Util::maxstr() instead, it
complains as it should:

~§ perl -wle 'use List::Util qw(maxstr); List::Util::maxstr($_ = "hi")
= 42; print'
Can't modify non-lvalue subroutine call in scalar assignment at -e
line 1, near "42;"
Execution of -e aborted due to compilation errors.

That said, we actually seem to have a problem with XS functions called
as methods.

Yeah, the keywords there seems to be "compilation errors". For methods
we have to detect this at runtime…

Yes, this is about calls that can't be resolved (and rejected) at
compile time. It affects all method calls but also this:

% perl -wle 'use List::Util qw(maxstr); (\&maxstr)->($_ = "hi") = 42; print'
42

i.e. calls through a reference.

--
Lukas Mai <plokinom@gmail.com>

p5pRT · 2013-05-28T01:03:26Z

From @cpansprout

On Mon May 13 12:18:21 2013, plokinom@gmail.com wrote:

On 13.05.2013 14:12, Leon Timmermans wrote:

On Mon, May 13, 2013 at 1:28 PM, Rafael Garcia-Suarez
<rgs@consttype.org> wrote:

maxstr is not a method; if you use List::Util::maxstr() instead, it
complains as it should:

~§ perl -wle 'use List::Util qw(maxstr); List::Util::maxstr($_ =
"hi")
= 42; print'
Can't modify non-lvalue subroutine call in scalar assignment at -e
line 1, near "42;"
Execution of -e aborted due to compilation errors.

That said, we actually seem to have a problem with XS functions
called
as methods.

Yeah, the keywords there seems to be "compilation errors". For
methods
we have to detect this at runtime…

Yes, this is about calls that can't be resolved (and rejected) at
compile time. It affects all method calls but also this:

% perl -wle 'use List::Util qw(maxstr); (\&maxstr)->($_ = "hi") = 42;
print'
42

i.e. calls through a reference.

I’ve just fixed this in 4587c53.

--

Father Chrysostomos

p5pRT · 2013-05-28T01:03:35Z

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

p5pRT · 2013-05-28T05:38:00Z

From @mauke

On 28.05.2013 03:03, Father Chrysostomos via RT wrote:

According to our records, your request regarding
"all XS functions are implicitly :lvalue"
has been resolved.

If you have any further questions or concerns, please respond to this message.

Nice, thanks for the quick fix! Will this be in 5.18.1?

--
Lukas Mai <l.mai@web.de>

p5pRT · 2013-06-05T05:48:07Z

From @tsee

On 05/28/2013 07:35 AM, Lukas Mai wrote:

On 28.05.2013 03:03, Father Chrysostomos via RT wrote:

According to our records, your request regarding
"all XS functions are implicitly :lvalue"
has been resolved.

If you have any further questions or concerns, please respond to this
message.

Nice, thanks for the quick fix! Will this be in 5.18.1?

IIRC it was in 5.16.3, so not a 5.18 regression. It doesn't affect
portability. It's not a security concern.

My reading of the policy is that it won't be in 5.18.1, I am afraid. I'd
be open to an exception if there was a good case for it (but in the end,
Rik's the one to decide).

--Steffen

p5pRT · 2013-06-05T14:14:25Z

From @nwc10

On Wed, Jun 05, 2013 at 07:47:12AM +0200, Steffen Mueller wrote:

On 05/28/2013 07:35 AM, Lukas Mai wrote:

On 28.05.2013 03:03, Father Chrysostomos via RT wrote:

According to our records, your request regarding
"all XS functions are implicitly :lvalue"
has been resolved.

If you have any further questions or concerns, please respond to this
message.

Nice, thanks for the quick fix! Will this be in 5.18.1?

IIRC it was in 5.16.3, so not a 5.18 regression. It doesn't affect
portability. It's not a security concern.

My reading of the policy is that it won't be in 5.18.1, I am afraid. I'd
be open to an exception if there was a good case for it (but in the end,
Rik's the one to decide).

But as it's a 5.16.x regression (ie compared with 5.14.x) it should be
backported to 5.16.4?

I'm somewhat playing devil's advocate here. The paragraph in question in
perlpolicy that you are reading is this?

Patches that fix regressions in perl's behavior relative to previous
releases are acceptable.

In which case "release*s*" suggests to me that it's fair game to consider
further than 5.14.0. But in the end, pragmatism needs to win, and it's
Ricardo's call on what's pragmatic.

Nicholas Clark

p5pRT · 2013-06-05T14:27:17Z

From @xdg

On Wed, Jun 5, 2013 at 10:13 AM, Nicholas Clark <nick@ccl4.org> wrote:

In which case "release*s*" suggests to me that it's fair game to consider
further than 5.14.0. But in the end, pragmatism needs to win, and it's
Ricardo's call on what's pragmatic.

FWIW, I think we should backport it to all relevant maint releases.

David

--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

p5pRT · 2013-06-05T14:34:10Z

From @nwc10

On Wed, Jun 05, 2013 at 10:25:53AM -0400, David Golden wrote:

On Wed, Jun 5, 2013 at 10:13 AM, Nicholas Clark <nick@ccl4.org> wrote:

In which case "release*s*" suggests to me that it's fair game to consider
further than 5.14.0. But in the end, pragmatism needs to win, and it's
Ricardo's call on what's pragmatic.

FWIW, I think we should backport it to all relevant maint releases.

Yes, I forgot to say, that this looks like the thing to do, as it's a
small change, seemingly self contained, and fixes a subtle bug which is
going to trip people up. (If it isn't already)

Nicholas Clark

p5pRT · 2013-06-06T04:33:49Z

From @cpansprout

On Wed Jun 05 07:34:10 2013, nicholas wrote:

On Wed, Jun 05, 2013 at 10:25:53AM -0400, David Golden wrote:

On Wed, Jun 5, 2013 at 10:13 AM, Nicholas Clark <nick@ccl4.org>
wrote:

In which case "release*s*" suggests to me that it's fair game to
consider
further than 5.14.0. But in the end, pragmatism needs to win, and
it's
Ricardo's call on what's pragmatic.

FWIW, I think we should backport it to all relevant maint releases.

Yes, I forgot to say, that this looks like the thing to do, as it's a
small change, seemingly self contained, and fixes a subtle bug which
is
going to trip people up. (If it isn't already)

I have back-ported it to maint-5.18 as dffdb99 and to maint-5.16 as
e5da327.

--

Father Chrysostomos

p5pRT · 2013-06-06T04:38:34Z

From @cpansprout

On Wed Jun 05 21:33:49 2013, sprout wrote:

On Wed Jun 05 07:34:10 2013, nicholas wrote:

On Wed, Jun 05, 2013 at 10:25:53AM -0400, David Golden wrote:

On Wed, Jun 5, 2013 at 10:13 AM, Nicholas Clark <nick@ccl4.org>
wrote:

In which case "release*s*" suggests to me that it's fair game to
consider
further than 5.14.0. But in the end, pragmatism needs to win, and
it's
Ricardo's call on what's pragmatic.

FWIW, I think we should backport it to all relevant maint releases.

Yes, I forgot to say, that this looks like the thing to do, as it's a
small change, seemingly self contained, and fixes a subtle bug which
is
going to trip people up. (If it isn't already)

I have back-ported it to maint-5.18 as dffdb99 and to maint-5.16 as
e5da327.

But I seem unable to get into cherrymaint. Is it down, or has the
address changed?

--

Father Chrysostomos

p5pRT · 2013-06-07T14:30:03Z

From @rjbs

* David Golden <xdg@xdg.me> [2013-06-05T10:25:53]

FWIW, I think we should backport it to all relevant maint releases.

It's already done, but +1 for the record.

--
rjbs

p5pRT · 2013-06-07T14:31:27Z

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06-06T00:38:35]

But I seem unable to get into cherrymaint. Is it down, or has the
address changed?

We haven't used that in some time. We've discussed recommencing, but for the
most part have used quick list threads or the "blocking 5.x.y" tickets instead.

--
rjbs

p5pRT · 2013-06-07T19:41:20Z

From @cpansprout

On Fri Jun 07 07:31:27 2013, perl.p5p@rjbs.manxome.org wrote:

* Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06-
06T00:38:35]

But I seem unable to get into cherrymaint. Is it down, or has the
address changed?

We haven't used that in some time. We've discussed recommencing, but
for the
most part have used quick list threads or the "blocking 5.x.y" tickets
instead.

That actually makes this easier, if you ask me. I was going to mark
this in cherrymaint simply as a courtesy, but now I am saved the bother.

--

Father Chrysostomos

p5pRT closed this as completed May 28, 2013

p5pRT added Severity Medium distro-Linux type-core labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

all XS functions are implicitly :lvalue #12955

all XS functions are implicitly :lvalue #12955

p5pRT commented May 10, 2013

p5pRT commented May 10, 2013

p5pRT commented May 13, 2013

p5pRT commented May 13, 2013

p5pRT commented May 13, 2013

p5pRT commented May 13, 2013

p5pRT commented May 13, 2013

p5pRT commented May 28, 2013

p5pRT commented May 28, 2013

p5pRT commented May 28, 2013

p5pRT commented Jun 5, 2013

p5pRT commented Jun 5, 2013

p5pRT commented Jun 5, 2013

p5pRT commented Jun 5, 2013

p5pRT commented Jun 6, 2013

p5pRT commented Jun 6, 2013

p5pRT commented Jun 7, 2013

p5pRT commented Jun 7, 2013

p5pRT commented Jun 7, 2013

all XS functions are implicitly :lvalue #12955

all XS functions are implicitly :lvalue #12955

Comments

p5pRT commented May 10, 2013

p5pRT commented May 10, 2013

From @mauke

Created by @mauke

p5pRT commented May 13, 2013

From @rgarcia

p5pRT commented May 13, 2013

p5pRT commented May 13, 2013

From @Leont

p5pRT commented May 13, 2013

From @mauke

p5pRT commented May 13, 2013

From @mauke

p5pRT commented May 28, 2013

From @cpansprout

p5pRT commented May 28, 2013

p5pRT commented May 28, 2013

From @mauke

p5pRT commented Jun 5, 2013

From @tsee

p5pRT commented Jun 5, 2013

From @nwc10

p5pRT commented Jun 5, 2013

From @xdg

p5pRT commented Jun 5, 2013

From @nwc10

p5pRT commented Jun 6, 2013

From @cpansprout

p5pRT commented Jun 6, 2013

From @cpansprout

p5pRT commented Jun 7, 2013

From @rjbs

p5pRT commented Jun 7, 2013

From @rjbs

p5pRT commented Jun 7, 2013

From @cpansprout