Open p5pRT opened 10 years ago
I noticed that "delete @x[@y]" can go wrong in the special case when @x and @y are identical. Example:
use warnings; my @array = (2\, 1\, 2); delete @array[@array]; # deleting from itself say "(@array)";
The response is Use of uninitialized value in delete at ./ttt line 11. ()
The warning is unexpected and the resulting array ought to still have 2 on index position 0. Indeed\, "delete @array[my @dup = @array]" shows the expected behavior. Apparently the special case of identical @x and @y needs more attention than it gets.
Regards\, Anno
Summary of my perl5 (revision 5 version 18 subversion 2) configuration:
Platform:
osname=darwin\, osvers=13.1.0\, archname=darwin-multi-2level
uname='darwin radom 13.1.0 darwin kernel version 13.1.0: thu jan 16 19:40:37 pst 2014; root:xnu-2422.90.20~2release_x86_64 x86_64 '
config_args='-des -Duseshrplib -Dusemultiplicity'
hint=recommended\, useposix=true\, d_sigaction=define
useithreads=undef\, usemultiplicity=define
useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef
use64bitint=define\, use64bitall=define\, uselongdouble=undef
usemymalloc=n\, bincompat5005=undef
Compiler:
cc='cc'\, ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include'\,
optimize='-O3'\,
cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include'
ccversion=''\, gccversion='4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)'\, 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='env MACOSX_DEPLOYMENT_TARGET=10.3 cc'\, ldflags =' -fstack-protector -L/usr/local/lib -L/opt/local/lib'
libpth=/usr/local/lib /opt/local/lib /usr/lib
libs=-lgdbm -ldbm -ldl -lm -lutil -lc
perllibs=-ldl -lm -lutil -lc
libc=\, so=dylib\, useshrplib=true\, libperl=libperl.dylib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs\, dlext=bundle\, d_dlsymun=undef\, ccdlflags=' '
cccdlflags=' '\, lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector'
Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF Built under darwin Compiled at Mar 17 2014 21:11:28 %ENV: PERL5LIB="/Users/anno/lib/perl5" PERLBREW_BASHRC_VERSION="0.42" PERLBREW_HOME="/Users/anno/.perlbrew" PERLBREW_MANPATH="" PERLBREW_PATH="/Users/anno/perl5/perlbrew/bin" PERLBREW_ROOT="/Users/anno/perl5/perlbrew" PERLBREW_VERSION="0.67" PERL_UNICODE="SALAD" @INC: /Users/anno/lib/perl5 /usr/local/lib/perl5/site_perl/5.18.2/darwin-multi-2level /usr/local/lib/perl5/site_perl/5.18.2 /usr/local/lib/perl5/5.18.2/darwin-multi-2level /usr/local/lib/perl5/5.18.2 /usr/local/lib/perl5/site_perl/5.18.1/darwin-multi-2level /usr/local/lib/perl5/site_perl/5.18.1 /usr/local/lib/perl5/site_perl/5.18.0/darwin-multi-2level /usr/local/lib/perl5/site_perl/5.18.0 /usr/local/lib/perl5/site_perl/5.16.1 /usr/local/lib/perl5/site_perl/5.16.0 /usr/local/lib/perl5/site_perl/5.14.2 /usr/local/lib/perl5/site_perl/5.14.1 /usr/local/lib/perl5/site_perl/5.14.0 /usr/local/lib/perl5/site_perl/5.12.3 /usr/local/lib/perl5/site_perl/5.12.1 /usr/local/lib/perl5/site_perl/5.12.0 /usr/local/lib/perl5/site_perl/5.10.1 /usr/local/lib/perl5/site_perl .
On Thu Apr 17 09:32:26 2014\, anno5@me.com wrote:
I noticed that "delete @x[@y]" can go wrong in the special case when @x and @y are identical. Example:
use warnings; my @array = (2\, 1\, 2); delete @array[@array]; # deleting from itself say "(@array)";
The response is Use of uninitialized value in delete at ./ttt line 11. ()
The warning is unexpected and the resulting array ought to still have 2 on index position 0. Indeed\, "delete @array[my @dup = @array]" shows the expected behavior.
I think this also is the expected behavior:
##### my @array = (2\, 1\, 2); my @second_array = (2\, 1\, 2); delete @array[@second_array]; say "(@array)"; ##### Output: (2) #####
The RT System itself - Status changed from 'new' to 'open'
On Thu Apr 17 09:32:26 2014\, anno5@me.com wrote:
I noticed that "delete @x[@y]" can go wrong in the special case when @x and @y are identical. Example:
use warnings; my @array = (2\, 1\, 2); delete @array[@array]; # deleting from itself say "(@array)";
The response is Use of uninitialized value in delete at ./ttt line 11. ()
The warning is unexpected and the resulting array ought to still have 2 on index position 0. Indeed\, "delete @array[my @dup = @array]" shows the expected behavior. Apparently the special case of identical @x and @y needs more attention than it gets.
Regards\, Anno
On the other hand\, 'perldoc -f delete' says:
##### WARNING: Calling delete on array values is deprecated and likely to be removed in a future version of Perl. ##### So maybe we shouldn't worry about this too much.
On Thu\, Jul 03\, 2014 at 06:18:54PM -0700\, James E Keenan via RT wrote:
On Thu Apr 17 09:32:26 2014\, anno5@me.com wrote:
I noticed that "delete @x[@y]" can go wrong in the special case when @x and @y are identical. Example:
use warnings; my @array = (2\, 1\, 2); delete @array[@array]; # deleting from itself say "(@array)";
The response is Use of uninitialized value in delete at ./ttt line 11. ()
The warning is unexpected and the resulting array ought to still have 2 on index position 0. Indeed\, "delete @array[my @dup = @array]" shows the expected behavior. Apparently the special case of identical @x and @y needs more attention than it gets.
Regards\, Anno
On the other hand\, 'perldoc -f delete' says:
##### WARNING: Calling delete on array values is deprecated and likely to be removed in a future version of Perl. ##### So maybe we shouldn't worry about this too much.
Perhaps.
But then\, IMO\, it should actually be removed\, instead of lingering around.
Abigail
Migrated from rt.perl.org#121677 (status was 'open')
Searchable as RT121677$