if ... elsif gives wrong line # for warning about undefined value #8133

p5pRT · 2005-09-28T20:46:01Z

Migrated from rt.perl.org#37302 (status was 'resolved')

Searchable as RT37302$

p5pRT · 2001-04-21T07:56:21Z

From @nwc10

I believe that the "wrong" line given by the warning inside an if elsif else
construction is known. However, why do I get:

nick@Bagpuss [PerlIO-gzip-0.09]$ perl Makefile.PL
Name "main::config" used only once: possible typo at Makefile.PL line 46.
Use of uninitialized value in pattern match (m//) at Makefile.PL line 29.

from this line (46)

} elsif ($config{cppccsymbols} =~ /\sunix=/ or $^O eq 'darwin') {

where line 29 is the start of the first if().

If the used once warning can get the line correct, why can't the undefined
warning?

[obviously my bug is that "config" should be "Config", but that doesn't
explain perl's schizophrenic behaviour]

Nicholas Clark

Perl Info


Flags:
    category=core
    severity=low

This perlbug was built using Perl v5.7.0 - Sun Mar 25 14:52:17 BST 2001
It is being executed now by  Perl v5.7.0 - Fri Mar 30 20:19:52 BST 2001.

Site configuration information for perl v5.7.0:

Configured by nick at Fri Mar 30 20:19:52 BST 2001.

Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.0-rmk3, archname=armv4l-linux
    uname='linux bagpuss.unfortu.net 2.4.0-rmk3 #3 sat jan 20 21:38:55 gmt 2001 armv4l unknown '
    config_args='-Dmksymlinks -Dusedevel -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@talking.bollo.cx -Dperladmin=nick@talking.bollo.cx -Dinc_version_list=  -Dinc_version_list_init=0 -de'
    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=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.2 20000220 (Debian GNU/Linux)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    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 -ldb -ldl -lm -lc -lposix -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
    libc=/lib/libc-2.1.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'

Locally applied patches:
    DEVEL9274


@INC for perl v5.7.0:
    /usr/local/lib/perl5/5.7.0/armv4l-linux
    /usr/local/lib/perl5/5.7.0
    /usr/local/lib/perl5/site_perl/5.7.0/armv4l-linux
    /usr/local/lib/perl5/site_perl/5.7.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.7.0:
    HOME=/home/nick
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=en_GB.ISO-8859-1
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/nick/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/sbin:/usr/sbin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2001-04-21T08:48:17Z

From @pjcj

I believe that the "wrong" line given by the warning inside an if elsif else
construction is known. However, why do I get:

nick@Bagpuss [PerlIO-gzip-0.09]$ perl Makefile.PL
Name "main::config" used only once: possible typo at Makefile.PL line 46.
Use of uninitialized value in pattern match (m//) at Makefile.PL line 29.

from this line (46)

} elsif ($config{cppccsymbols} =~ /\sunix=/ or $^O eq 'darwin') {

where line 29 is the start of the first if().

I think you'll find that that it is for the same reason.

If the used once warning can get the line correct, why can't the undefined
warning?

The undefined warning isn't given until the code is executed, by which
time line number of the elsif is lost and the most accurate line
information is at the start of the if().

You can confirm this by doing something like

perl -MO=Deparse,-l Makefile.PL

or

perl -MO=Concise Makefile.PL

if you really want the gory details.

p5pRT · 2001-06-08T05:28:21Z

From wolfgang.laun@alcatel.at

#! /usr/bin/perl -w
use strict;
my $foo = 1;
if( $foo == 1 ){
# do this
} elsif( $foo == 2 ){
# do that
#... more of the same ...
} elsif( foo == 1001 ){
# ...
}

produces the diagnostic

Bareword "foo" not allowed while "strict subs" in use at ./bug.pl line 4.
Execution of ./bug.pl aborted due to compilation errors.

The line number shown (4) is the one of the if statement, but,
pampered as we are, we would prefer it to be the one of the line
containing the error.

The line no is correct if there is a syntax error, so this is probably
restricted to diagnostics resulting from `use strict'.

Perl Info


Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by dberg at Wed Mar 21 11:22:35 MET 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos atusels1 5.5.1 generic_103640-31 sun4u sparc '
    config_args='-Dcc=gcc -Dprefix=/usr/GNU'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='gcc', optimize='-O', gccversion=2.9-gnupro-99r1p1
    cppflags='-fno-strict-aliasing'
    ccflags ='-fno-strict-aliasing '
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' '
    libpth=/tag/mt/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt -lsec
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E'
    cccdlflags='-fPIC', lddlflags=' -W,l-E -G'

Locally applied patches:
    


@INC for perl v5.6.0:
    /usr/GNU/lib/perl5/5.6.0/sun4-solaris
    /usr/GNU/lib/perl5/5.6.0
    /usr/GNU/lib/perl5/site_perl/5.6.0/sun4-solaris
    /usr/GNU/lib/perl5/site_perl/5.6.0
    /usr/GNU/lib/perl5/site_perl
    .


Environment for perl v5.6.0:
    HOME=/users/tas/laune
    LANG=
    LANGUAGE (unset)
    LD_LIBRARY_PATH=
    LOGDIR (unset)
    PATH=:/users/el486t/cygnus/gnubin/solaris/sun4/bin:/tools/rational/releases/ClearQuestClient.2001.03.00/bin::/users/tas/el_vobadm/setup:/users/tas/el_vobadm/setup/../bin:/usr/atria/bin:/tools/pure/bin:/usr/openwin/bin:/usr/GNU/bin:/tools/tex/solaris/bin:/usr/X11R6/bin:/usr/local/bin:/usr/AAA/bin:/usr/bin:/usr/ucb:/elektra/tools/make_sys:/elektra/vobs/makehome/scripts:/users/tas/laune/bin
    PERL_BADLANG (unset)
    SHELL=/usr/GNU/bin/bash

p5pRT · 2001-06-08T06:32:39Z

From @floatingatoll

Now, I can speculate a bit from here.

-- begin speculation

perly.y, line 207. It's getting the line number, but the line number is
INACCURATE - it's the line number for the last statement we parsed that
updated the line number - usually an if() or something inside an if().

Solution? Get the line number up to date right here at this line, so
that the warnings are correct.

Maybe that's not possible, for some reason. Okay. How about the line
number of the *next* statement? That way at least we're *closer* to the
general vicinity of the correct place then before.

-- end speculation

Of course, I don't even know where to start with the speculations, but
that's what I'd explore to fix this idea. HTH, HAND.

R.

-----Original Message-----
From: Wolfgang Laun [mailto:wolfgang.laun@alcatel.at]
Sent: Friday, June 08, 2001 5:28 AM
To: perl5-porters@perl.org
Cc: perlbug@rfi.net
Subject: [ID 20010608.004] compile time error in elsif
printed with line
no of if

This is a bug report for perl from wolfgang.laun@alcatel.at,
generated with the help of perlbug 1.28 running under perl v5.6.0.

-----------------------------------------------------------------
[Please enter your report here]

#! /usr/bin/perl -w
use strict;
my $foo = 1;
if( $foo == 1 ){
# do this
} elsif( $foo == 2 ){
# do that
#... more of the same ...
} elsif( foo == 1001 ){
# ...
}

produces the diagnostic

Bareword "foo" not allowed while "strict subs" in use at
./bug.pl line 4.
Execution of ./bug.pl aborted due to compilation errors.

The line number shown (4) is the one of the if statement, but,
pampered as we are, we would prefer it to be the one of the line
containing the error.

The line no is correct if there is a syntax error, so this is probably
restricted to diagnostics resulting from `use strict'.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.6.0:

Configured by dberg at Wed Mar 21 11:22:35 MET 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 0)
configuration:
Platform:
osname=solaris, osvers=2.5.1, archname=sun4-solaris
uname='sunos atusels1 5.5.1 generic_103640-31 sun4u sparc '
config_args='-Dcc=gcc -Dprefix=/usr/GNU'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef
usesocks=undef
Compiler:
cc='gcc', optimize='-O', gccversion=2.9-gnupro-99r1p1
cppflags='-fno-strict-aliasing'
ccflags ='-fno-strict-aliasing '
stdchar='unsigned char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=4
alignbytes=8, usemymalloc=y, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' '
libpth=/tag/mt/lib /lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt -lsec
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E'
cccdlflags='-fPIC', lddlflags=' -W,l-E -G'

Locally applied patches:

---
@INC for perl v5.6.0:
/usr/GNU/lib/perl5/5.6.0/sun4-solaris
/usr/GNU/lib/perl5/5.6.0
/usr/GNU/lib/perl5/site_perl/5.6.0/sun4-solaris
/usr/GNU/lib/perl5/site_perl/5.6.0
/usr/GNU/lib/perl5/site_perl
.

---
Environment for perl v5.6.0:
HOME=/users/tas/laune
LANG=
LANGUAGE (unset)
LD_LIBRARY_PATH=
LOGDIR (unset)

PATH=:/users/el486t/cygnus/gnubin/solaris/sun4/bin:/tools/rati
onal/releases/ClearQuestClient.2001.03.00/bin::/users/tas/el_v
obadm/setup:/users/tas/el_vobadm/setup/../bin:/usr/atria/bin:/
tools/pure/bin:/usr/openwin/bin:/usr/GNU/bin:/tools/tex/solari
s/bin:/usr/X11R6/bin:/usr/local/bin:/usr/AAA/bin:/usr/bin:/usr
/ucb:/elektra/tools/make_sys:/elektra/vobs/makehome/scripts:/u
sers/tas/laune/bin
PERL_BADLANG (unset)
SHELL=/usr/GNU/bin/bash

p5pRT · 2004-04-06T04:29:56Z

From @jlokier

Created by @jlokier

This small program illustrates the bug:

if (0) {
} elsif (${+undef} = 0) {
}

The output is:

Can't use an undefined value as a SCALAR reference at - line 1.

It _should_ say line 2, not line 1. This is pretty confusing if you
don't know about it and you get a run time error.

Compile time errors are fine. For this program:

if (0) {
} elsif ("x" = 2) {
}

the output is:

Can't modify constant item in scalar assignment at - line 2, near "2) "

Enjoy,
-- Jamie

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.0:

Configured by bhcompile'
cf_email='bhcompile at Wed Aug 13 11:45:59 EDT 2003.

Summary of my rderl (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi
    uname='linux str'
    config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef'
 useithreads=define usemultiplicity=
    useperlio= d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=un uselongdouble=
    usemymalloc=, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers=''
gccversion='3.2.2 200302'
    intsize=r, longsize=r, ptrsize=5, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long'
k', ivsize=4'
ivtype='l, nvtype='double'
o_nonbl', nvsize=, Off_t='', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc'
l', ldflags =' -L/u'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
    perllibs=
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC'
ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s Unicode/Normalize XS/A'

Locally applied patches:
    MAINT18379


@INC for perl v5.8.0:
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/5.8.0
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/5.8.0
    .


Environment for perl v5.8.0:
    HOME=/home/jamie
    LANG=en_GB.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jamie/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash
    dlflags='-share (unset)

p5pRT · 2004-04-07T08:06:20Z

From @rgs

Jamie Lokier (via RT) wrote:

This small program illustrates the bug:
if $0$ \{
\} elsif $$\{\+undef\} = 0$ \{
\}
The output is:
Can't use an undefined value as a SCALAR reference at \- line 1\.
It _should_ say line 2, not line 1. This is pretty confusing if you
don't know about it and you get a run time error.

There is a whole class of problems like this that are due to the way
perl remembers line numbers in the compiled code. Basically they are
stored only at statement boundaries, not at each op. perl thus reports
the line number of the current statement. Add to this the fact that
some statements are optimized away, yacc's handling of error recovery
and lookahead, and probably some black magic performed by the lexer
in double-quoted strings, and you'll end up with the assurance that
it's pretty impossible to guarantee a correct line number in error
messages in all cases.

Compile time errors are fine. For this program:
if $0$ \{
\} elsif $"x" = 2$ \{
\}
the output is:
Can't modify constant item in scalar assignment at \- line 2\, near "2\) "

p5pRT · 2004-04-07T08:06:25Z

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

p5pRT · 2005-09-28T20:46:02Z

From ludemann@yahoo-inc.com

Created by ludemann@yahoo-inc.com

My problem code had something like this:

if (defined $a && $a =~ m/.../) { # line 1 <== got warning about this
...
} elsif ($b =~ m/.../) { # line 3 <== but real problem was here
...
} else {
...
}

This was getting an occasional, clearly bogus, warning about an
undefined variable in line 1. The actual undefined variable was in
line 3.

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.1:

Configured by rr at Thu Mar  7 23:10:53 PST 2002.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=freebsd, osvers=4, archname=i386-freebsd
    uname='FreeBSD pkgbuild2.corp.yahoo.com 4.1-YAHOO-20001028 FreeBSD 4.1-YAHOO-20001028 #0: Sat Dec  1 16:59:23 PST 2001     root@pkgbuild2.corp.yahoo.com:/home/obj/home/src/sys/YAHOO  i386'
    config_args=''
    hint=previous, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='gcc', ccflags ='-fno-strict-aliasing -I/home/y/include -I/usr/local/include -march=pentiumpro -pipe',
    optimize='-g -O2',
    cppflags='-fno-strict-aliasing -I/home/y/include -I/usr/local/include -march=pentiumpro -pipe'
    ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='freebsdelf'
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-Wl,-E  -L/home/y/lib -L/usr/local/lib'
    libpth=/usr/lib /home/y/lib /usr/local/lib
    libs=-lm -lc -lcrypt -lutil
    perllibs=-lm -lc -lcrypt -lutil
    libc=, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -Wl,-R/home/y/lib/perl5/5.6.1/i386-freebsd/CORE -Wl,-R/home/y/lib -Wl,-R/usr/local/lib'
    cccdlflags='-DPIC -fpic', lddlflags='-shared  -L/home/y/lib -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.1:
    /home/y/lib/perl5/5.6.1/i386-freebsd
    /home/y/lib/perl5/5.6.1
    /home/y/lib/perl5/site_perl/5.6.1/i386-freebsd
    /home/y/lib/perl5/site_perl/5.6.1
    /home/y/lib/perl5/site_perl
    .


Environment for perl v5.6.1:
    HOME=/homes/ludemann
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/homes/ludemann/bin:/homes/ludemann/script:/home/y/bin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/usr/common/bin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

p5pRT · 2005-09-29T10:09:47Z

From @ysth

On Wed, Sep 28, 2005 at 01:46:02PM -0700, ludemann @ yahoo-inc. com wrote:

My problem code had something like this:

if (defined $a && $a =~ m/.../) { # line 1 <== got warning about this
...
} elsif ($b =~ m/.../) { # line 3 <== but real problem was here
...
} else {
...
}

This was getting an occasional, clearly bogus, warning about an
undefined variable in line 1. The actual undefined variable was in
line 3.

This is because the undefined value is tripped over in a statement
that begins on line 1. I believe last time this was brought up,
there may have been a discussion of how to make it work as expected.
Can anybody else find it in the archives?

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

Can anyone suggest something other than "pattern match (m//)" that
would make this clear? (If there's an undefined value on the right,
it says "in regex compilation" instead.)

p5pRT · 2005-09-29T10:09:54Z

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

p5pRT · 2005-09-29T10:36:39Z

From sts@accognoscere.org

On Wed, Sep 28, 2005 at 01:46:02PM -0700, ludemann@yahoo-inc.com (via RT) wrote:

# New Ticket Created by ludemann@yahoo-inc.com
# Please include the string: [perl #37302]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=37302 >

This is a bug report for perl from ludemann@yahoo-inc.com,
generated with the help of perlbug 1.33 running under perl v5.6.1.

-----------------------------------------------------------------
[Please enter your report here]

My problem code had something like this:

if (defined $a && $a =~ m/.../) { # line 1 <== got warning about this
...
} elsif ($b =~ m/.../) { # line 3 <== but real problem was here
...
} else {
...
}

This was getting an occasional, clearly bogus, warning about an
undefined variable in line 1. The actual undefined variable was in
line 3.

That's most likely due to the way the optimizer works; that's not only
true for your situation encountered above, but also for several other
warnings - they don't inevitably refer to the line where the mistake
took place (see what happens if you omit a single trailing semicolon).

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

"Use of uninitialized value in pattern match (m//)" is definitely referring
to the value of the variable being processed against a regular expression,
because a regular expression can never be uninitialized; all that can be,
is that the expression given does not match.

Excerpt from 'perldoc perldiag':

Use of uninitialized value%s

(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.

To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, C<"that $foo"> is
usually optimized into C<"that " . $foo>, and the warning will refer to
the C<concatenation (.)> operator, even though there is no C<.> in your
program.

Steven

p5pRT · 2005-09-29T11:18:15Z

From @pjcj

On Wed, Sep 28, 2005 at 01:46:02PM -0700, ludemann@yahoo-inc.com wrote:

My problem code had something like this:

if (defined $a && $a =~ m/.../) { # line 1 <== got warning about this
...
} elsif ($b =~ m/.../) { # line 3 <== but real problem was here
...
} else {
...
}

This was getting an occasional, clearly bogus, warning about an
undefined variable in line 1. The actual undefined variable was in
line 3.

The problem here is that there is no information in the optree
referring to the elsif line. This can be seen from running B::Concise,
for example.

$ perl5.9.3 -MO=Concise -we 'if ($a) {}
elsif ($a + 1) {}'
1 <0> enter ->2
2 <;> nextstate(main 4 -e:1) v ->3
- <1> null vKP/1 ->6
4 <|> cond_expr(other->5) vK/1 ->7
- <1> ex-rv2sv sK/1 ->4
3 <$> gvsv(*a) s ->4
- <@> scope vK ->-
5 <0> stub v ->6
- <1> null vK/1 ->-
a <|> and(other->b) vK/1 ->6
9 <2> add[t1] sK/2 ->a
- <1> ex-rv2sv sK/1 ->8
7 <$> gvsv(*a) s ->8
8 <$> const(IV 1) s ->9
- <@> scope vK ->-
b <0> stub v ->6

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

I won't disagree there, but rightly or wrongly (OK, wrongly) people parse error
messages and so you might have a problem getting that one past the backwards
compatibility police.

However, were the problem with an uninitialised value in the pattern
the message would be "Use of uninitialized value in regexp compilation".
In bleadperl you will even be told which variable is causing the message
(thanks Dave!) which should reduce confusion further.

Of course, if you are still running 5.6.1 then it might be a while
before you get that benefit. I sympathise, my work work is on 5.005_03.

--
Paul Johnson - paul@pjcj.net
http://www.pjcj.net

p5pRT · 2005-09-29T12:28:20Z

From sts@accognoscere.org

On Thu, Sep 29, 2005 at 03:09:14AM -0700, Yitzchak Scott-Thoennes wrote:

On Wed, Sep 28, 2005 at 01:46:02PM -0700, ludemann @ yahoo-inc. com wrote:

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

Can anyone suggest something other than "pattern match (m//)" that
would make this clear? (If there's an undefined value on the right,
it says "in regex compilation" instead.)

"Use of uninitialized value in variable being pattern matched"?

Although, that could be misunderstood too. But I guess, it's at least
slightly less confusing.

Other ideas?

p5pRT · 2005-09-30T11:49:26Z

From david@landgren.net

Steven Schubiger wrote:

On Thu, Sep 29, 2005 at 03:09:14AM -0700, Yitzchak Scott-Thoennes wrote:

On Wed, Sep 28, 2005 at 01:46:02PM -0700, ludemann @ yahoo-inc. com wrote:

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

Can anyone suggest something other than "pattern match (m//)" that
would make this clear? (If there's an undefined value on the right,
it says "in regex compilation" instead.)

"Use of uninitialized value in variable being pattern matched"?

Although, that could be misunderstood too. But I guess, it's at least
slightly less confusing.

Other ideas?

"applying a pattern to match undefined value at line n"
"attempt to match undefined value against a pattern at line n"
"attempt to match undefined value at line n"

The issue at hand, however, is that the OP is interested in
disambiguating the C<if> and C<elsif>. If the operations are the same,
the warning is the same.

David
--
"It's overkill of course, but you can never have too much overkill."

p5pRT · 2005-09-30T12:05:35Z

From @rgs

Paul Johnson wrote:

The problem here is that there is no information in the optree
referring to the elsif line. This can be seen from running B::Concise,
for example.

Without adding the equivalent of cop_line and cop_file to OP_SCOPE,
and making the core deal with it everywhere (setting PL_curcop, etc),
this can't be improved. This is likely to cause performance decreases.

--
Upward behind the onstreaming it mooned.
-- Borges

p5pRT · 2005-09-30T13:47:14Z

From @iabyn

On Fri, Sep 30, 2005 at 01:48:20PM +0200, David Landgren wrote:

"applying a pattern to match undefined value at line n"
"attempt to match undefined value against a pattern at line n"
"attempt to match undefined value at line n"

Unless we put in some special-case code, the warning is always going to
be of the form

"Use of uninitialized value" . <optional variable name> . " in "
. <description of operator currently being executed>

--
Technology is dominated by two types of people: those who understand what
they do not manage, and those who manage what they do not understand.

p5pRT · 2005-10-13T00:47:02Z

From @smpeters

[ludemann@yahoo-inc.com - Wed Sep 28 13:46:02 2005]:

This is a bug report for perl from ludemann@yahoo-inc.com,
generated with the help of perlbug 1.33 running under perl v5.6.1.

-----------------------------------------------------------------
[Please enter your report here]

My problem code had something like this:

if (defined $a && $a =~ m/.../) { # line 1 <== got warning about
this
...
} elsif ($b =~ m/.../) { # line 3 <== but real problem was here
...
} else {
...
}

This was getting an occasional, clearly bogus, warning about an
undefined variable in line 1. The actual undefined variable was in
line 3.

(BTW, the message "Use of uninitialized value in pattern match
(m//)" could be improved ... it's not clear whether the pattern
contains an uninitialized value or the value that's being pattern
matched is uninitialized.)

Hmmm...the past repeats itself...

#6837 - line number dichotomy on warnings
#7097 - compile time error in elsif printed with line no of if
#28282 - Wrong line number for errors in "elsif" conditions

Well, I can at least merge all these old tickets in with this one.

p5pRT · 2008-04-18T13:46:49Z

From @rgs

This bug has been fixed by change #33710.

p5pRT · 2008-04-18T13:47:02Z

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

p5pRT closed this as completed Apr 18, 2008

p5pRT added Severity Low distro-freebsd type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

if ... elsif gives wrong line # for warning about undefined value #8133

if ... elsif gives wrong line # for warning about undefined value #8133

p5pRT commented Sep 28, 2005

p5pRT commented Apr 21, 2001

p5pRT commented Apr 21, 2001

p5pRT commented Jun 8, 2001

p5pRT commented Jun 8, 2001

p5pRT commented Apr 6, 2004

p5pRT commented Apr 7, 2004

p5pRT commented Apr 7, 2004

p5pRT commented Sep 28, 2005

p5pRT commented Sep 29, 2005

p5pRT commented Sep 29, 2005

p5pRT commented Sep 29, 2005

p5pRT commented Sep 29, 2005

p5pRT commented Sep 29, 2005

p5pRT commented Sep 30, 2005

p5pRT commented Sep 30, 2005

p5pRT commented Sep 30, 2005

p5pRT commented Oct 13, 2005

p5pRT commented Apr 18, 2008

p5pRT commented Apr 18, 2008

if ... elsif gives wrong line # for warning about undefined value #8133

if ... elsif gives wrong line # for warning about undefined value #8133

Comments

p5pRT commented Sep 28, 2005

p5pRT commented Apr 21, 2001

From @nwc10

p5pRT commented Apr 21, 2001

From @pjcj

p5pRT commented Jun 8, 2001

From wolfgang.laun@alcatel.at

p5pRT commented Jun 8, 2001

From @floatingatoll

p5pRT commented Apr 6, 2004

From @jlokier

Created by @jlokier

p5pRT commented Apr 7, 2004

From @rgs

p5pRT commented Apr 7, 2004

p5pRT commented Sep 28, 2005

From ludemann@yahoo-inc.com

Created by ludemann@yahoo-inc.com

p5pRT commented Sep 29, 2005

From @ysth

p5pRT commented Sep 29, 2005

p5pRT commented Sep 29, 2005

From sts@accognoscere.org

p5pRT commented Sep 29, 2005

From @pjcj

p5pRT commented Sep 29, 2005

From sts@accognoscere.org

p5pRT commented Sep 30, 2005

From david@landgren.net

p5pRT commented Sep 30, 2005

From @rgs

p5pRT commented Sep 30, 2005

From @iabyn

p5pRT commented Oct 13, 2005

From @smpeters

p5pRT commented Apr 18, 2008

From @rgs

p5pRT commented Apr 18, 2008