From Albert_N._MICHEEV@f80.n5049.z2.fidonet.org

Ex1​:
  @​_ = map{
  $_ += 1;
  }qw/5 2 7 0 7 7/;

  Exception​: Modification of a read-only value attempted at 1.pl line 1

Ex2​:
  @​_ = map{
  $_ += 1;
  }(5,2,7,0,7,7);

  Exception​: Modification of a read-only value attempted at 1.pl line 1

Ex3​:
  @​_ = map{
  $_ += 1;
  }1..6;

  All OK

???

P.S.

perl -v

This is perl, v5.6.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

From [Unknown Contact. See original ticket]

Albert N. MICHEEV writes​:

Ex2​:
@​_ = map{
$_ += 1;
}(5,2,7,0,7,7);

Exception​: Modification of a read-only value attempted at 1.pl line 1

Why are you surprised? Did you mean map {$_ + 1} ?

Ilya

From @tamias

On Sat, Apr 15, 2000 at 01​:54​:11PM -0400, Ilya Zakharevich wrote​:

Albert N. MICHEEV writes​:

Ex2​:
@​_ = map{
$_ += 1;
}(5,2,7,0,7,7);

Exception​: Modification of a read-only value attempted at 1.pl line 1

Why are you surprised? Did you mean map {$_ + 1} ?

He's surprised because this doesn't produce the same error​:

@​_ = map {
  $_ += 1;
} 1 .. 6;

Ronald

From [Unknown Contact. See original ticket]

On Sat, Apr 15, 2000 at 02​:01​:44PM -0400, Ronald J Kimball wrote​:

Ex2​:
@​_ = map{
$_ += 1;
}(5,2,7,0,7,7);

Exception​: Modification of a read-only value attempted at 1.pl line 1

Why are you surprised? Did you mean map {$_ + 1} ?

He's surprised because this doesn't produce the same error​:

@​_ = map {
$_ += 1;
} 1 .. 6;

Oh, *this* bug​:

perl -wle "sub a {map {print; ++$_} 1..3} a;print'';a"
1
2
3

2
3
4

It was discussed here many years ago already. It is my long-held
opinion that these values (produced at compile time) should be marked
read-only.

Ilya

From @jhi

On Sat, Apr 15, 2000 at 02​:31​:35PM -0400, Ilya Zakharevich wrote​:

On Sat, Apr 15, 2000 at 02​:01​:44PM -0400, Ronald J Kimball wrote​:

Ex2​:
@​_ = map{
$_ += 1;
}(5,2,7,0,7,7);

Exception​: Modification of a read-only value attempted at 1.pl line 1

Why are you surprised? Did you mean map {$_ + 1} ?

He's surprised because this doesn't produce the same error​:

@​_ = map {
$_ += 1;
} 1 .. 6;

Oh, *this* bug​:

perl -wle "sub a {map {print; ++$_} 1..3} a;print'';a"
1
2
3

2
3
4

It was discussed here many years ago already. It is my long-held
opinion that these values (produced at compile time) should be marked
read-only.

$opinion = 'agreed';
$patches = 'welcome';

Ilya

From @jhi

On Sat, Apr 15, 2000 at 02​:31​:35PM -0400, Ilya Zakharevich wrote​:

On Sat, Apr 15, 2000 at 02​:01​:44PM -0400, Ronald J Kimball wrote​:

Ex2​:
@​_ = map{
$_ += 1;
}(5,2,7,0,7,7);

Exception​: Modification of a read-only value attempted at 1.pl line 1

Why are you surprised? Did you mean map {$_ + 1} ?

He's surprised because this doesn't produce the same error​:

@​_ = map {
$_ += 1;
} 1 .. 6;

Oh, *this* bug​:

perl -wle "sub a {map {print; ++$_} 1..3} a;print'';a"
1
2
3

2
3
4

It was discussed here many years ago already. It is my long-held
opinion that these values (produced at compile time) should be marked
read-only.

There's also this​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-07/msg00059.html

Ilya

From dmacks@netspace.org

map { $_="X" } ( "a" .. "b" ); # [1]
map { $_="X" } (qw/ a b c / ); # [2]

Why does Perl not complain about [1]? It seems (to me, at least)
that it should give rise to "Modification of a read-only value
attempted" like [2] does. The same goes for grep.

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by dmacks at Mon Apr  3 10:41:03 EDT 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.0.36, archname=i686-linux-64all
    uname='linux netspace.org 2.0.36 #4 mon jan 11 22:49:47 est 1999 i686 unknown '
    config_args=''
    hint=previous, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=define use64bitall=define uselongdouble=define usesocks=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.7.2.3
    cppflags='-DPERL_Y2KWARN -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    ccflags ='-DPERL_Y2KWARN -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=4
    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=/lib/libc-2.0.7.so, 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'

Locally applied patches:
    


@INC for perl v5.6.0:
    /home/dmacks/lib/perl5/5.6.0/i686-linux
    /home/dmacks/lib/perl5/5.6.0
    /home/dmacks/lib/perl5/site_perl/5.6.0/i686-linux
    /home/dmacks/lib/perl5/site_perl/5.6.0
    /home/dmacks/lib/perl5/site_perl
    .


Environment for perl v5.6.0:
    HOME=/home/dmacks
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/dmacks/bin:/usr/kerberos/bin:/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin:/usr/sbin:/usr/games:.
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

From @floatingatoll

On Tue, 30 Jan 2001 dmacks@​netspace.org wrote​:

map { $_="X" } ( "a" .. "b" ); # [1]
map { $_="X" } (qw/ a b c / ); # [2]

Why does Perl not complain about [1]? It seems (to me, at least)
that it should give rise to "Modification of a read-only value
attempted" like [2] does. The same goes for grep.

$ perl -e 'map { print ++$_ . "\n" } ( 0 .. 2 )'
1
2
3
$ perl -e 'map { print ++$_ . "\n" } ( 'x' .. 'z' )'
y
z
aa

The range expansion section in toke.c doesn't mark the SV read only when
it's done expanding - there could be more than just a range, if I read the
code correctly. It's a bit weird in there.

R.

From @Abigail

Created by @Abigail

  $, = " "; $\ = "\n";
  sub f {@​_ [0, 1] = @​_ [1, 0]; @​_}
  print f 1, 2;
  __END__

This will give an error message​:
Modification of a read-only value attempted at /tmp/xx line 2

However​:
  $, = " "; $\ = "\n";
  sub f {@​_ [0, 1] = @​_ [1, 0]; @​_}
  print f 1 .. 2;
  __END__

prints​:
  2 1

I think both programs should be behave identical.

Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.1:

Configured by abigail at Tue Jul 10 12:17:49 CEST 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.4.5, archname=i686-linux-64int-ld
    uname='linux hermione 2.4.5 #6 fri jun 22 01:38:20 pdt 2001 i686 unknown '
    config_args='-d -Dprefix=/opt/perl -Doptimize=-g -Dusemorebits'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=define
  Compiler:
    cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/opt/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/opt/local/include'
    ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib -L/opt/local/lib'
    libpth=/usr/local/lib /opt/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.3.so, 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 -L/opt/local/lib'

Locally applied patches:
    


@INC for perl v5.6.1:
    /home/abigail/Perl
    /home/abigail/Sybase
    /opt/perl/lib/5.6.1/i686-linux-64int-ld
    /opt/perl/lib/5.6.1
    /opt/perl/lib/site_perl/5.6.1/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.6.1
    /opt/perl/lib/site_perl
    .


Environment for perl v5.6.1:
    HOME=/home/abigail
    LANG (unset)
    LANGUAGE (unset)
    LC_ALL=POSIX
    LD_LIBRARY_PATH=/home/abigail/Lib:/usr/local/lib:/usr/lib:/lib:/usr/X11R6/lib:/opt/gnome/lib
    LOGDIR (unset)
    PATH=/home/abigail/Bin:/opt/perl/bin:/usr/local/bin:/usr/local/X11/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/games:/opt/povray/bin:/opt/gnome/bin:/opt/opera/bin:/usr/share/texmf/bin:/opt/Acrobat4/bin:/opt/java/blackdown/j2sdk1.3.1/bin:/usr/local/games/bin:/opt/gnuplot/bin:/opt/mysql/bin
    PERL5LIB=/home/abigail/Perl:/home/abigail/Sybase
    PERLDIR=/opt/perl
    PERL_BADLANG (unset)
    SHELL=/usr/bin/bash

From @rgarcia

On 2002.04.12 16​:42 abigail@​foad.org wrote​:

$\, = " "; $\\ = "\\n";
sub f \{@​\_ \[0\, 1\] = @​\_ \[1\, 0\]; @​\_\}
print f 1\, 2;
\_\_END\_\_

This will give an error message​:
Modification of a read-only value attempted at /tmp/xx line 2

However​:
$, = " "; $\ = "\n";
sub f {@​_ [0, 1] = @​_ [1, 0]; @​_}
print f 1 .. 2;
__END__

prints​:
2 1

I think both programs should be behave identical.

Using B​::Concise shows that the latter constructs an array.
In other words, it's roughly equivalent to

  print f @​{ [1,2] };

which prints "2 1".

Does this count as a Feature (tm) ? In the 1..2
case, Perl doesn't know at compile-time the number of
arguments passed to f (the compilation would have failed
if f had a $$ prototype). (Yes, Perl *could* expand constants
n..m lists at compile-time, but currently it doesn't.)

From [Unknown Contact. See original ticket]

Rafael Garcia-Suarez wrote​:

On 2002.04.12 16​:42 abigail@​foad.org wrote​:

$\, = " "; $\\ = "\\n";
sub f \{@​\_ \[0\, 1\] = @​\_ \[1\, 0\]; @​\_\}
print f 1\, 2;
\_\_END\_\_

This will give an error message​:
Modification of a read-only value attempted at /tmp/xx line 2

However​:
$, = " "; $\ = "\n";
sub f {@​_ [0, 1] = @​_ [1, 0]; @​_}
print f 1 .. 2;
__END__

prints​:
2 1

I think both programs should be behave identical.

Using B​::Concise shows that the latter constructs an array.
In other words, it's roughly equivalent to

    print f @​\{ \[1\,2\] \};

which prints "2 1".

Does this count as a Feature (tm) ?

Not really, since
  perl -e "print map chop, 1..2 for 1..2"
prints​: 12, rather than 1212.

In the 1..2 case, Perl doesn't know at compile-time the number of
arguments passed to f (the compilation would have failed
if f had a $$ prototype). (Yes, Perl *could* expand constants
n..m lists at compile-time, but currently it doesn't.)

I think that the problem is that it should expand n..m lists into real
lists, rather than arrays. I don't think that this expansion should be
done at compile time (especially if it's a big range)... but rather, it
should be indistinguishable from an expansion that was done at runtime.

--
print reverse( ",rekcah", " lreP", " rehtona", " tsuJ" )."\n";

From @ask

FWIW,

this is still an issue with 5.6.1 and 5.8.0.

- ask

From @schwern

Still an issue in 5.8.6 and bleadperl.

From module@renee-baecker.de

On Mo. 13. Dez. 2004, 20​:19​:40, schwern wrote​:

Still an issue in 5.8.6 and bleadperl.

Still an issue in Perl 5.10.0

rbaecker@​www-devel-rbaecker ~/perl510/test/perl-5.10.0 $ perl -wle 'my
@​list = map{ $_ += 1 }(1,2,3)'
Modification of a read-only value attempted at -e line 1.
rbaecker@​www-devel-rbaecker ~/perl510/test/perl-5.10.0 $ perl -wle 'my
@​list = map{ $_ += 1 }(1..3)'
rbaecker@​www-devel-rbaecker ~/perl510/test/perl-5.10.0 $ perl
-MO=Concise,-exec -wle 'my @​list = map{ $_ += 1 }1..3'
1 <0> enter
2 <;> nextstate(main 2 -e​:1) v
3 <0> pushmark s
4 <0> pushmark s
5 <$> const(AV ) s
6 <1> rv2av lKPM/1
7 <@​> mapstart lK*/2
8 <|> mapwhile(other->9)[t5] lK/1
9 <0> enter l
a <;> nextstate(main 1 -e​:1) v
b <$> gvsv(*_) s
c <$> const(IV 1) s
d <2> add[t2] sKS/2
e <@​> leave lKP
  goto 8
f <0> pushmark s
g <0> padav[@​list​:2,3] lRM*/LVINTRO
h <2> aassign[t6] vKS
i <@​> leave[1 ref] vKP/REFC
-e syntax OK
rbaecker@​www-devel-rbaecker ~/perl510/test/perl-5.10.0 $ perl
-MO=Concise,-exec -wle 'my @​list = map{ $_ += 1 }(1,2,3)'
1 <0> enter
2 <;> nextstate(main 2 -e​:1) v
3 <0> pushmark s
4 <0> pushmark s
5 <$> const(IV 1) sM
6 <$> const(IV 2) sM
7 <$> const(IV 3) sM
8 <@​> mapstart lK*/2
9 <|> mapwhile(other->a)[t3] lK/1
a <0> enter l
b <;> nextstate(main 1 -e​:1) v
c <$> gvsv(*_) s
d <$> const(IV 1) s
e <2> add[t2] sKS/2
f <@​> leave lKP
  goto 9
g <0> pushmark s
h <0> padav[@​list​:2,3] lRM*/LVINTRO
i <2> aassign[t4] vKS
j <@​> leave[1 ref] vKP/REFC
-e syntax OK

From module@renee-baecker.de

Related Ticket​: http​://rt.perl.org/rt3/Public/Bug/Display.html?id=3105

From module@renee-baecker.de

Related Ticket​: http​://rt.perl.org/rt3/Public/Bug/Display.html?id=5564

From @xdg

Confirmed still exists in 5.11.1

From @ikegami

The severity of this bug can be demonstrated using

$ perl -e'sub f { for (1..5,@​x) { print ++$_ } print "\n"; } f;f;'
23456
34567

In other words, accidentally changing the list can have repercussions
later in the program.

From @obra

On Wed, Nov 25, 2009 at 05​:29​:01PM -0500, Eric Brine wrote​:

On Wed, Nov 25, 2009 at 3​:33 PM, Abigail <abigail@​abigail.be> wrote​:

I've no suggestion to do it differently. I'm just pointing out the patch
comes with a price - it may break code. I've no opinion on whether that
price is one we want to pay.

Since fixing the bug can have negative effects, we could deprecate in 5.12
(by adding Set magic to the returned values), fix in 5.14.

I'm afraid you've missed the cutoff for deprecating things in 5.12.
Certainly, it's worth continuing to clean up and get ready to propose a
fix for 5.13.

From @iabyn

Eric notes that he pending work on this ticket

From @jkeenan

On Fri Nov 20 10​:36​:05 2009, ikegami@​adaelis.com wrote​:

The severity of this bug can be demonstrated using

$ perl -e'sub f { for (1..5,@​x) { print ++$_ } print "\n"; } f;f;'
23456
34567

Confirmed same behavior found in 5.14.2.

From @cpansprout

On Sun Nov 06 06​:43​:00 2011, jkeen@​verizon.net wrote​:

On Fri Nov 20 10​:36​:05 2009, ikegami@​adaelis.com wrote​:

The severity of this bug can be demonstrated using

$ perl -e'sub f { for (1..5,@​x) { print ++$_ } print "\n"; } f;f;'
23456
34567

Confirmed same behavior found in 5.14.2.

I proposed a solution to this involving the PADTMP flag​:
httphttp​://www.nntp.perl.org/group/perl.perl5.porters/2011/07/msg175152.html

I don’t know how well it will work.

--

Father Chrysostomos

From @cpansprout

Fixed in 5608dcc.

--

Father Chrysostomos

From [Unknown Contact. See original ticket]

Fixed in 5608dcc.

--

Father Chrysostomos

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