From listphilgoetz@gmail.com

$perl -v
This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

Accessing an array using slices does not ordinarily insert undefs into
the list, even if those positions are not in the array​:

my @​x = ();
print "First 4 elements of \@​x = @​x[0 .. 3]\n"; # Does not change @​x
my $size = scalar(@​x);
print "size of \@​x=$size\n"; # Did not change @​x

However, if you pass an array slice as an argument, it does​:

sub foo {}
&foo(@​x[0.. 3]);
my $size = scalar(@​x);
print "size of \@​x=$size\n"; # Changed @​x; now x = (undef undef undef undef)

- Phil Goetz

Flags:
    category=core
    severity=low

Site configuration information for perl 5.10.1:

Configured by root at Mon Oct 19 13:11:37 EDT 2009.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=2.6.18-53.1.4.el5, archname=x86_64-linux-thread-multi
    uname='linux speedy 2.6.18-53.1.4.el5 #1 smp wed nov 14 10:37:27 est 2007 x86_64 x86_64 x86_64 gnulinux '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O3',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.1.2', 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', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.5.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/packages/perl-5.10.1/lib/5.10.1/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O3 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.10.1:
    /usr/local/common/perl/lib/bioperl-1.6.1/lib/perl5/Bio
    /home/pgoetz/.cpan32/lib
    /usr/local/packages/perl-5.10.1/lib/5.10.1
    /usr/local/packages/perl-5.10.1/lib/5.10.1
    /usr/local/common/perl/lib
    .


Environment for perl 5.10.1:
    HOME=/home/pgoetz
    LANG=en_US
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/export/lib
    LOGDIR (unset)
    PATH=/usr/local/sge_current/bin/lx24-amd64:/usr/local/packages/EMBOSS/bin:/data/bin:/usr/local/devel/ANNOTATION/glimmer/glimmer3.01/bin:/usr/local/packages/glimmer-2.13:/usr/local/archive/home/pgoetz/pan/bin:/usr/local/archive/home/pgoetz/pan/ext/orthoMcl/bin:/home/pgoetz/.cpan64/bin:/usr/local/packages/tmake/bin:/home/pgoetz/bin:/usr/local/bin:/usr/local/common:/usr/bin:/bin:/opt/gnome/bin:/opt/kde3/bin:/opt/lam/bin:/usr/local/sge_current/bin/lx24-amd64:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/X11R6/bin:/opt/real/RealPlayer
    PERL5LIB=/usr/local/common/perl/lib/bioperl-1.6.1/lib/perl5/Bio:/home/pgoetz/.cpan32/lib
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From ambrus@math.bme.hu

On Wed, May 18, 2011 at 10​:21 PM, original via RT
<perlbug-followup@​perl.org> wrote​:

Accessing an array using slices does not ordinarily insert undefs into
the list, even if those positions are not in the array​:

However, if you pass an array slice as an argument, it does​:

sub foo {}
&foo(@​x[0.. 3]);
my $size = scalar(@​x);
print "size of \@​x=$size\n";    # Changed @​x; now x = (undef undef undef undef)

I believe this is not a bug. When you call a function, the array
elements are passed by reference, so if some element does not yet
exist, it has to be created so that you can have a reference.

See also "http​://www.perlmonks.com/?node_id=455749".

Ambrus

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

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

@ikegami - Status changed from 'rejected' to 'open'

From @cpansprout

If we change this, we probably need to modify the ‘Why does passing a
subroutine an undefined element in a hash create it?’ entry in perlfaq4.

From @jkeenan

On Fri May 20 22​:20​:26 2011, sprout wrote​:

If we change this, we probably need to modify the ‘Why does passing a
subroutine an undefined element in a hash create it?’ entry in perlfaq4.

So, should we actually change it?

Thank you very much.
Jim Keenan

From @jkeenan

On Fri Feb 15 18​:40​:50 2013, jkeenan wrote​:

On Fri May 20 22​:20​:26 2011, sprout wrote​:

If we change this, we probably need to modify the ‘Why does passing a
subroutine an undefined element in a hash create it?’ entry in perlfaq4.

So, should we actually change it?

No one has spoken up for changing this in the five months since I posed
the question.

I am taking this ticket for the purpose of closing it in seven days
unless someone wishes to take the ticket over and move the discussion
forward.

Thank you very much.
Jim Keenan

From @cpansprout

On Fri Jul 12 18​:27​:50 2013, jkeenan wrote​:

On Fri Feb 15 18​:40​:50 2013, jkeenan wrote​:

On Fri May 20 22​:20​:26 2011, sprout wrote​:

If we change this, we probably need to modify the ‘Why does passing a
subroutine an undefined element in a hash create it?’ entry in
perlfaq4.

So, should we actually change it?

No one has spoken up for changing this in the five months since I posed
the question.

I am taking this ticket for the purpose of closing it in seven days
unless someone wishes to take the ticket over and move the discussion
forward.

Actually, I do think we should change it. But it will cause bug #77814
to occur more often, so that one needs to be fixed first. (I’m adding a
dependency.)

--

Father Chrysostomos