undef "looks like" a number #7168

p5pRT · 2004-03-12T19:54:35Z

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

Searchable as RT27606$

p5pRT · 2004-03-12T19:54:35Z

From zefram@fysh.org

Created by zefram@fysh.org

$ perl -MScalar::Util=looks_like_number -we 'print looks_like_number(undef), " ", 0+undef,"\n"'
Use of uninitialized value in addition (+) at -e line 1.
1 0

looks_like_number() returns true for undef, even though Perl actually
complains if undef is used as a number. I think looks_like_number()
should be consistent with Perl's warnings.

I guess this is related to the "return 1; /* Historic. Wrong? */"
in Perl_looks_like_number() in sv.c.

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.3:

Configured by Debian Project at Sun Feb 15 17:22:09 EST 2004.

Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.4.22-xfs+ti1211, archname=i386-linux-thread-multi
    uname='linux kosh 2.4.22-xfs+ti1211 #1 sat oct 25 10:11:37 est 2003 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.3 -Dsitearch=/usr/local/lib/perl/5.8.3 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.3 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O3',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.3.3 20040125 (prerelease) (Debian)', gccosandvers=''
    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, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.3
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.3:
    /etc/perl
    /usr/local/lib/perl/5.8.3
    /usr/local/share/perl/5.8.3
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8
    /usr/share/perl/5.8
    /usr/local/lib/site_perl
    .


Environment for perl v5.8.3:
    HOME=/home/zefram
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/zefram/pub/i686-pc-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/bin:/usr/games:/opt/libunsn/bin
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

p5pRT · 2004-03-14T01:49:54Z

From @mhx

On 2004-03-12, at 19:54:36 -0000, Zefram (via RT) wrote:

# New Ticket Created by Zefram
# Please include the string: [perl #27606]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27606 >

This is a bug report for perl from zefram@fysh.org,
generated with the help of perlbug 1.34 running under perl v5.8.3.

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

$ perl -MScalar::Util=looks_like_number -we 'print looks_like_number(undef), " ", 0+undef,"\n"'
Use of uninitialized value in addition (+) at -e line 1.
1 0

looks_like_number() returns true for undef, even though Perl actually
complains if undef is used as a number. I think looks_like_number()
should be consistent with Perl's warnings.

I guess this is related to the "return 1; /* Historic. Wrong? */"
in Perl_looks_like_number() in sv.c.

Yes, it's related to that line. The comment was added by this patch:

Change 10463 by jhi@alpha on 2001/06/06 23:15:30

Subject: Re: [PATCH] nuke strtol (was Re: One fix for strtoul not setting errno)
From: Nicholas Clark <nick@ccl4.org>
Date: Thu, 7 Jun 2001 00:29:59 +0100
Message-ID: <20010607002959.Z76396@plum.flirble.org>

The line itself seems to be _very_ old. The current behaviour is strange
(in my eyes), but known and even checked, e.g. in ext/List/Util/t/lln.t:

ok(!!looks_like_number(undef), 1);

However, there was a recent discussion about undef, which revealed...

Chip Salzenberg <chip@pobox.com> wrote:

According to Gisle Aas:

Marcus Holland-Moritz <mhx-perl@gmx.net> writes:

That makes sense. But then, what should undef..undef return?

Same as 0..0, i.e. 0.

No, that's a Bad Idea. Nowhere else in Perl is undef interpreted
preferentially as a number rather than a string. Why here?

Chip Salzenberg <chip@pobox.com> wrote:

According to Marcus Holland-Moritz:

I'd personally favor (d), because if both margins of a range are
undefined, you can't tell what the range should be.

No, no, a hundred times no! In all of Perl[1], undef is
indistinguishable from ''. Changing that would be Very Evil.

[1] The only exceptions are the very special defined() operator, which
exists specifically for the purpose, and human-purposed diagnostics.

So, it seems there's at least one other exception: looks_like_number()
treats undef as a number. According to the above, this can be considered
a bug.

Even though it could be "fixed" easily, I'm not sure if it should be.

Marcus

--
BOFH Excuse #78:

Yes, yes, its called a design limitation

p5pRT · 2004-03-14T01:49:55Z

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

p5pRT · 2004-03-14T13:06:05Z

From zefram@fysh.org

Addendum: typeglobs suffer the same problem:

$ perl -MScalar::Util=looks_like_number -we 'print looks_like_number(*foo), " ", 0+*foo,"\n"'
Argument "*main::foo" isn't numeric in addition (+) at -e line 1.
1 0

-zefram

p5pRT · 2004-03-14T21:32:18Z

From @rgs

Marcus Holland-Moritz wrote:

So, it seems there's at least one other exception: looks_like_number()
treats undef as a number. According to the above, this can be considered
a bug.

Even though it could be "fixed" easily, I'm not sure if it should be.

Difficult to say without knowing the implications; a quick inspection
of the sources tend to suggest that this should be fixed.

p5pRT · 2004-03-15T21:17:21Z

From @mhx

On 2004-03-14, at 22:30:37 +0100, Rafael Garcia-Suarez wrote:

Marcus Holland-Moritz wrote:

So, it seems there's at least one other exception: looks_like_number()
treats undef as a number. According to the above, this can be considered
a bug.

Even though it could be "fixed" easily, I'm not sure if it should be.

Difficult to say without knowing the implications; a quick inspection
of the sources tend to suggest that this should be fixed.

The attached patch should do it. At least it doesn't
break any core tests besides the one I've adjusted.

Apply at your own risk ;-)

--
The bomb will never go off. I speak as an expert in explosives.
-- Admiral William Leahy, U.S. Atomic Bomb Project

p5pRT · 2004-03-15T21:17:21Z

From @mhx

lln.diff

--- sv.c.orig	2004-03-14 02:25:46.000000000 +0100
+++ sv.c	2004-03-14 02:29:30.000000000 +0100
@@ -1909,7 +1909,7 @@
     else if (SvPOKp(sv))
 	sbegin = SvPV(sv, len);
     else
-	return 1; /* Historic.  Wrong?  */
+	return SvFLAGS(sv) & (SVf_NOK|SVp_NOK|SVf_IOK|SVp_IOK);
     return grok_number(sbegin, len, NULL);
 }
 
--- pp_ctl.c.orig	2004-03-15 19:50:40.000000000 +0100
+++ pp_ctl.c	2004-03-15 21:53:08.000000000 +0100
@@ -1058,8 +1058,9 @@
 #define RANGE_IS_NUMERIC(left,right) ( \
 	SvNIOKp(left)  || (SvOK(left)  && !SvPOKp(left))  || \
 	SvNIOKp(right) || (SvOK(right) && !SvPOKp(right)) || \
-	(((!SvOK(left) && SvOK(right)) || (looks_like_number(left) && \
-	  SvPOKp(left) && *SvPVX(left) != '0')) && looks_like_number(right)))
+	(((!SvOK(left) && SvOK(right)) || ((!SvOK(left) || \
+          looks_like_number(left)) && SvPOKp(left) && *SvPVX(left) != '0')) \
+         && (!SvOK(right) || looks_like_number(right))))
 
 PP(pp_flop)
 {
--- ext/List/Util/t/lln.t.orig	2004-03-15 21:04:53.000000000 +0100
+++ ext/List/Util/t/lln.t	2004-03-15 21:10:33.000000000 +0100
@@ -41,7 +41,7 @@
 ok(!!looks_like_number("Infinity"), $] >= 5.008);
 ok(!!looks_like_number("NaN"),	    $] >= 5.008);
 ok(!!looks_like_number("foo"),	    '');
-ok(!!looks_like_number(undef),	    1);
+ok(!!looks_like_number(undef),	    '');
 # That's enough - we trust the perl core tests like t/base/num.t
 
 __END__

p5pRT · 2004-03-18T20:19:42Z

From @rgs

Marcus Holland-Moritz wrote:

On 2004-03-14, at 22:30:37 +0100, Rafael Garcia-Suarez wrote:

Marcus Holland-Moritz wrote:

So, it seems there's at least one other exception: looks_like_number()
treats undef as a number. According to the above, this can be considered
a bug.

Even though it could be "fixed" easily, I'm not sure if it should be.

Difficult to say without knowing the implications; a quick inspection
of the sources tend to suggest that this should be fixed.

The attached patch should do it. At least it doesn't
break any core tests besides the one I've adjusted.

I think you're welcome to apply this, after you've adjusted ext/List/Util/t/lln.t
to take into account the different result for perl-version >= 5.9.2 (bleadperl
is now at 5.9.2), unless Graham comments otherwise.

p5pRT · 2005-04-08T03:29:05Z

From @smpeters

[rafael - Thu Mar 18 12:19:42 2004]:

Marcus Holland-Moritz wrote:

On 2004-03-14, at 22:30:37 +0100, Rafael Garcia-Suarez wrote:

Marcus Holland-Moritz wrote:

So, it seems there's at least one other exception:
looks_like_number()
treats undef as a number. According to the above, this can be
considered
a bug.

Even though it could be "fixed" easily, I'm not sure if it
should be.

Difficult to say without knowing the implications; a quick
inspection
of the sources tend to suggest that this should be fixed.

The attached patch should do it. At least it doesn't
break any core tests besides the one I've adjusted.

I think you're welcome to apply this, after you've adjusted
ext/List/Util/t/lln.t
to take into account the different result for perl-version >= 5.9.2
(bleadperl
is now at 5.9.2), unless Graham comments otherwise.

It appears that this change was applied with change #22662.

p5pRT · 2005-04-08T03:29:07Z

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

p5pRT closed this as completed Apr 8, 2005

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

undef "looks like" a number #7168

undef "looks like" a number #7168

p5pRT commented Mar 12, 2004

p5pRT commented Mar 12, 2004

p5pRT commented Mar 14, 2004

p5pRT commented Mar 14, 2004

p5pRT commented Mar 14, 2004

p5pRT commented Mar 14, 2004

p5pRT commented Mar 15, 2004

p5pRT commented Mar 15, 2004

p5pRT commented Mar 18, 2004

p5pRT commented Apr 8, 2005

p5pRT commented Apr 8, 2005

undef "looks like" a number #7168

undef "looks like" a number #7168

Comments

p5pRT commented Mar 12, 2004

p5pRT commented Mar 12, 2004

From zefram@fysh.org

Created by zefram@fysh.org

p5pRT commented Mar 14, 2004

From @mhx

p5pRT commented Mar 14, 2004

p5pRT commented Mar 14, 2004

From zefram@fysh.org

p5pRT commented Mar 14, 2004

From @rgs

p5pRT commented Mar 15, 2004

From @mhx

p5pRT commented Mar 15, 2004

From @mhx

p5pRT commented Mar 18, 2004

From @rgs

p5pRT commented Apr 8, 2005

From @smpeters

p5pRT commented Apr 8, 2005