undefined scalar doesn't cause fatal error when defererenced as array #14580

p5pRT · 2015-03-13T09:33:22Z

Migrated from rt.perl.org#124060 (status was 'open')

Searchable as RT124060$

p5pRT · 2015-03-13T09:33:22Z

From @dk

Created by @dk

Hello,

It seems that we've hit a discrepancy in how undefined scalars are
treated when used in array context vs list context. For example:

perl -E 'use warnings; use strict; use Data::Dumper; my $array_ref=undef; say Dumper($array_ref); foreach my $element (@$array_ref) { say $element } say Dumper($array_ref)'

produces

$VAR1 = undef;

$VAR1 = [];

where we would expect at least a fatal error like "Can't use an undefined value as an ARRAY reference"
and probably $array_ref won't be autovivified (not 100% sure about this though). As a reference, when I try the following code

perl -E 'use warnings; use strict; use Data::Dumper; my $array_ref=undef; say Dumper($array_ref); foreach my $element (()=@$array_ref) { say $element } say Dumper($array_ref)'

then it dies as expected.

Versions up to 5.20 are affected.

Sincerely
Dmitry Karasik

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl 5.14.2:

Configured by Debian Project at Tue Feb  4 23:09:53 UTC 2014.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=2.6.42-37-generic, archname=x86_64-linux-gnu-thread-multi
    uname='linux panlong 2.6.42-37-generic #58-ubuntu smp thu jan 24 15:28:10 utc 2013 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
    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='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.6.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='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
    gnulibc_version='2.15'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.14.2:
    /etc/perl
    /usr/local/lib/perl/5.14.2
    /usr/local/share/perl/5.14.2
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.14
    /usr/share/perl/5.14
    /usr/local/lib/site_perl
    .


Environment for perl 5.14.2:
    HOME=/z/home/adsj
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_NUMERIC=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/z/home/nzdb_prod/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/z/home/adsj/bin:/z/bio/biotools/signalp-3.0:/z/bio/biotools/R-1.8.1/bin:/z/bio/biotools/phylip:/z/bio/biotools/ViennaRNA1.5/bin:/z/bio/biotools/hmmer-2.3.2/bin:/z/bio/biotools/hmmer-1.8.4/bin:/z/bio/biotools/bin:/z/bio/erfam/bin/
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2015-03-14T23:03:39Z

From @jkeenan

On Fri Mar 13 02:33:22 2015, int32 wrote:

This is a bug report for perl from dmitry@karasik.eu.org,
generated with the help of perlbug 1.39 running under perl 5.14.2.

-----------------------------------------------------------------
[Please describe your issue here]

Hello,

It seems that we've hit a discrepancy in how undefined scalars are
treated when used in array context vs list context. For example:

perl -E 'use warnings; use strict; use Data::Dumper; my
$array_ref=undef; say Dumper($array_ref); foreach my $element
(@$array_ref) { say $element } say Dumper($array_ref)'

produces

$VAR1 = undef;

$VAR1 = [];

where we would expect at least a fatal error like "Can't use an
undefined value as an ARRAY reference"
and probably $array_ref won't be autovivified (not 100% sure about
this though). As a reference, when I try the following code

perl -E 'use warnings; use strict; use Data::Dumper; my
$array_ref=undef; say Dumper($array_ref); foreach my $element
(()=@$array_ref) { say $element } say Dumper($array_ref)'

then it dies as expected.

Versions up to 5.20 are affected.

Sincerely
Dmitry Karasik

And to demonstrate that this is not just another bug in Data::Dumper:

#####
$ perl -Mstrict -MData::Dump=pp -E 'my $array_ref=undef; pp($array_ref); for my $el (@$array_ref) { say "<$el>" } pp($array_ref);'
undef
[]

$ perl -Mstrict -MData::Dump=pp -E 'my $array_ref=undef; pp($array_ref); for my $el (()=@$array_ref) { say "<$el>" } pp($array_ref);'
undef
Can't use an undefined value as an ARRAY reference at -e line 1.
#####

--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2015-03-14T23:03:39Z

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

p5pRT · 2015-03-14T23:22:58Z

From bitcard@profvince.com

It seems that we've hit a discrepancy in how undefined scalars are
treated when used in array context vs list context. For example:

perl -E 'use warnings; use strict; use Data::Dumper; my
$array_ref=undef; say Dumper($array_ref); foreach my $element
(@$array_ref) { say $element } say Dumper($array_ref)'

produces

$VAR1 = undef;

$VAR1 = [];

where we would expect at least a fatal error like "Can't use an
undefined value as an ARRAY reference"
and probably $array_ref won't be autovivified (not 100% sure about
this though)

The list over which a for loop iterates is evaluated in lvalue context, because its elements can be changed by assigning to $_ (or whatever topic variable you use). Knowing this, what you observe is just the usual autovivification behaviour. In particular, note that both :

@$array_ref = ();
foo(@$array_ref);

do not cause the "Can't use an undefined value as an ARRAY reference" stricture exception either, for the same reasons.

It is pretty unrealistic to consider that this behaviour will ever change (it'd require a lot of work, would probably cause an important performance hit, and would break a lot of existing code), so I suggest closing the ticket.

Vincent

p5pRT · 2015-03-16T00:43:51Z

From @ikegami

On Sat, Mar 14, 2015 at 7:22 PM, Vincent Pit via RT <
perlbug-followup@perl.org> wrote:

It is pretty unrealistic to consider that this behaviour will ever change
(it'd require a lot of work, would probably cause an important performance
hit, and would break a lot of existing code), so I suggest closing the
ticket.

I don't see how it would cause a performance hit or break a lot of existing
code to not vivify a reference in foreach's list or in a sub call's
argument list.

That said, I don't see a problem here. Especially since the behaviour can
be controlled using the "autovivification" pragma.

p5pRT · 2015-03-16T00:45:04Z

From @ikegami

On Sun, Mar 15, 2015 at 8:43 PM, Eric Brine <ikegami@adaelis.com> wrote:

On Sat, Mar 14, 2015 at 7:22 PM, Vincent Pit via RT <
perlbug-followup@perl.org> wrote:

It is pretty unrealistic to consider that this behaviour will ever change
(it'd require a lot of work, would probably cause an important performance
hit, and would break a lot of existing code), so I suggest closing the
ticket.

I don't see how it would cause a performance hit or break a lot of
existing code to not vivify a reference in foreach's list or in a sub
call's argument list.

It would definitely cause problems to make it fatal, though.

That said, I don't see a problem here. Especially since the behaviour can

be controlled using the "autovivification" pragma.

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

xenu removed the affects-5.14 label Nov 19, 2021

xenu removed the Severity Medium label Dec 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

undefined scalar doesn't cause fatal error when defererenced as array #14580

undefined scalar doesn't cause fatal error when defererenced as array #14580

p5pRT commented Mar 13, 2015

p5pRT commented Mar 13, 2015

p5pRT commented Mar 14, 2015

p5pRT commented Mar 14, 2015

p5pRT commented Mar 14, 2015

p5pRT commented Mar 16, 2015

p5pRT commented Mar 16, 2015

undefined scalar doesn't cause fatal error when defererenced as array #14580

undefined scalar doesn't cause fatal error when defererenced as array #14580

Comments

p5pRT commented Mar 13, 2015

p5pRT commented Mar 13, 2015

From @dk

Created by @dk

p5pRT commented Mar 14, 2015

From @jkeenan

p5pRT commented Mar 14, 2015

p5pRT commented Mar 14, 2015

From bitcard@profvince.com

p5pRT commented Mar 16, 2015

From @ikegami

p5pRT commented Mar 16, 2015

From @ikegami