From pcg@goof.com

Created by pcg@goof.com

I am not sure this is actually a bug, I couldn't quite find hard
documentation on how the behaviour should be, but I only looked at
perldata.

There is a difference between pre-extending an array by assigning $#a and
filling with undef explicitly​:

  # perl -e '$#a = 1; map $_->{x}, @​a'
  Modification of a read-only value attempted at -e line 1.

  # perl -e '@​a = (undef); map $_->{x}, @​a'

Now the question is wether they should behave the same (preferably like
the second version, i.e. just work), or wether pre-extending an array
fills it with rather magical values.

Flags:
    category=core
    severity=wishlist

Site configuration information for perl v5.8.6:

Configured by Marc Lehmann at Tue Nov 30 00:54:44 CET 2004.

Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
  Platform:
    osname=linux, osvers=2.6.10-rc1, archname=amd64-linux
    uname='linux cerebro 2.6.10-rc1 #1 smp mon nov 22 05:47:21 cet 2004 x86_64 gnulinux '
    config_args='-Duselargefiles -Dxuse64bitint -Uxuse64bitall -Dusemymalloc=y -Dcc=gcc-3.4 -Dccflags=-ggdb -Dcppflags=-D_GNU_SOURCE -I/opt/include -Doptimize=-O4 -march=opteron -mtune=opteron -funroll-loops -fno-strict-aliasing -Dcccdlflags=-fPIC -Dldflags=-L/opt/perl/lib -L/opt/lib -Dlibs=-ldl -lm -lcrypt -Darchname=amd64-linux -Dprefix=/opt/perl -Dprivlib=/opt/perl/lib/perl5 -Darchlib=/opt/perl/lib/perl5 -Dvendorprefix=/opt/perl -Dvendorlib=/opt/perl/lib/perl5 -Dvendorarch=/opt/perl/lib/perl5 -Dsiteprefix=/opt/perl -Dsitelib=/opt/perl/lib/perl5 -Dsitearch=/opt/perl/lib/perl5 -Dsitebin=/opt/perl/bin -Dman1dir=/opt/perl/man/man1 -Dman3dir=/opt/perl/man/man3 -Dsiteman1dir=/opt/perl/man/man1 -Dsiteman3dir=/opt/perl/man/man3 -Dman1ext=1 -Dman3ext=3 -Dpager=/usr/bin/less -Uafs -Uusesfio -Uusenm -Uuseshrplib -Dd_dosuid -Dusethreads=undef -Duse5005threads=undef -Duseithreads=undef -Dusemultiplicity=undef -Demail=perl-binary@plan9.de -Dcf_email=perl-binary@plan9.de -Dcf_by=Marc Lehmann -Dlocincpth=/opt/perl/include /opt/include -Dmyhostname=localhost -Dmultiarch=undef -Dbin=/opt/perl/bin -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=define uselongdouble=undef
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='gcc-3.4', ccflags ='-ggdb -fno-strict-aliasing -pipe -I/opt/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O4 -march=opteron -mtune=opteron -funroll-loops -fno-strict-aliasing',
    cppflags='-D_GNU_SOURCE -I/opt/include -ggdb -fno-strict-aliasing -pipe -I/opt/include'
    ccversion='', gccversion='3.4.2 (Debian 3.4.2-3)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc-3.4', ldflags ='-L/opt/perl/lib -L/opt/lib -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-ldl -lm -lcrypt
    perllibs=-ldl -lm -lcrypt
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/opt/perl/lib -L/opt/lib -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.6:
    /root/src/sex
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    .


Environment for perl v5.8.6:
    HOME=/root
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=de_DE.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/root/s2:/root/s:/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/games:/root/src/uunet:.
    PERL5LIB=/root/src/sex
    PERL5_CPANPLUS_CONFIG=/root/.cpanplus/config
    PERLDB_OPTS=ornaments=0
    PERL_BADLANG (unset)
    PERL_UNICODE=EAL
    SHELL=/bin/bash

From @TimToady

On Fri, Mar 10, 2006 at 08​:53​:09AM -0800, Marc Lehmann wrote​:
: # New Ticket Created by Marc Lehmann
: # Please include the string​: [perl #38703]
: # in the subject line of all future correspondence about this issue.
: # <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=38703 >
:
:
:
: This is a bug report for perl from pcg@​goof.com,
: generated with the help of perlbug 1.35 running under perl v5.8.6.
:
:
: -----------------------------------------------------------------
: [Please enter your report here]
:
:
: I am not sure this is actually a bug, I couldn't quite find hard
: documentation on how the behaviour should be, but I only looked at
: perldata.

Mmm, it's kind of implied by the doc for exists().

: There is a difference between pre-extending an array by assigning $#a and
: filling with undef explicitly​:
:
: # perl -e '$#a = 1; map $_->{x}, @​a'
: Modification of a read-only value attempted at -e line 1.
:
: # perl -e '@​a = (undef); map $_->{x}, @​a'
:
: Now the question is wether they should behave the same (preferably like
: the second version, i.e. just work), or wether pre-extending an array
: fills it with rather magical values.

Well, the intent of the design was that exists() should allow for
testing element existence apart from definedness so that sparse
arrays can be represented using the array interface and not just
the hash interface. I can argue the design decision either way,
and certainly the question of whether the default implementation
should use an array of 0 pointers to indicate sparseness is another
question, but I don't think anyone would argue that sparse arrays
aren't occasionally useful...

Larry

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

From schmorp@schmorp.de

On Fri, Mar 10, 2006 at 05​:42​:33PM -0800, Larry Wall via RT <perlbug-followup@​perl.org> wrote​:

: documentation on how the behaviour should be, but I only looked at
: perldata.

Mmm, it's kind of implied by the doc for exists().

Hmm... "kind of", I agree. I wouldn't be able to deduce the behaviour for
pre-extended arrays, though, but I see wehre it comes from.

the hash interface. I can argue the design decision either way,
and certainly the question of whether the default implementation
should use an array of 0 pointers to indicate sparseness is another
question, but I don't think anyone would argue that sparse arrays
aren't occasionally useful...

Well, not to me, but I cna easily come up with useful cases, even if I never
needed them *g*.

Now the question is why they shouldn't auto-vivify. But this is probably
an artefact of the implementation (e.g. they actually do auto-vivify in
some contexts, but not in others).

In any case, feel free to close this report, its not a big deal to me, I just
thought somebody should look over this and decide wether its a bug or a
feature :)

--
  The choice of a
  -----==- _GNU_
  ----==-- _ generation Marc Lehmann
  ---==---(_)__ __ ____ __ pcg@​goof.com
  --==---/ / _ \/ // /\ \/ / http​://schmorp.de/
  -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE

From @nwc10

On Sun, Mar 12, 2006 at 01​:33​:37AM +0100, Marc Lehmann wrote​:

On Fri, Mar 10, 2006 at 05​:42​:33PM -0800, Larry Wall via RT <perlbug-followup@​perl.org> wrote​:

: documentation on how the behaviour should be, but I only looked at
: perldata.

Mmm, it's kind of implied by the doc for exists().

Hmm... "kind of", I agree. I wouldn't be able to deduce the behaviour for
pre-extended arrays, though, but I see wehre it comes from.

the hash interface. I can argue the design decision either way,
and certainly the question of whether the default implementation
should use an array of 0 pointers to indicate sparseness is another
question, but I don't think anyone would argue that sparse arrays
aren't occasionally useful...

Well, not to me, but I cna easily come up with useful cases, even if I never
needed them *g*.

Now the question is why they shouldn't auto-vivify. But this is probably
an artefact of the implementation (e.g. they actually do auto-vivify in
some contexts, but not in others).

My gut feeling was that they should auto-vivify, so the example you provided

  $ perl -e '$#a = 1; map $_->{x}, @​a'
  Modification of a read-only value attempted at -e line 1.

demonstrates a bug in the implementation. I think that these two should be
functionally equivalent​:

$ perl -e '$#a = 3; $_ = 1 foreach @​a'
$ perl -e '$#a = 3; map {$_ = 1} @​a'
Modification of a read-only value attempted at -e line 1.

Nicholas Clark

From schmorp@schmorp.de

On Mon, Mar 13, 2006 at 09​:08​:36AM -0800, Nicholas Clark via RT <perlbug-followup@​perl.org> wrote​:

Now the question is why they shouldn't auto-vivify. But this is probably
an artefact of the implementation (e.g. they actually do auto-vivify in
some contexts, but not in others).

My gut feeling was that they should auto-vivify, so the example you provided

Well, the documentation is, after all, not correct as it does say they
won'T auto-vivify, but I don't think anybody cares if they do, as opposed
tot he other way round.

$ perl -e '$#a = 3; $_ = 1 foreach @​a'
$ perl -e '$#a = 3; map {$_ = 1} @​a'
Modification of a read-only value attempted at -e line 1.

That is interesting. I would have supposed that map and foreach both work
the same (and that perl can't auto-vivify through the $_ aliased to the
array element. But with for, it can. Cool :->

Yes, I'd say that this inconsistency is indeed a bug, regardless of how it
is supposed to work.

--
  The choice of a
  -----==- _GNU_
  ----==-- _ generation Marc Lehmann
  ---==---(_)__ __ ____ __ pcg@​goof.com
  --==---/ / _ \/ // /\ \/ / http​://schmorp.de/
  -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE

p5p@spam.wizbit.be - Status changed from 'open' to 'stalled'