From @sisyphus

Created by @sisyphus

There was a bug report from a long time back about this.
It was closed a while ago and, since I couldn't find it to
re-open it, I've decided to to write a new report.
I think the closing of that report happened because it was
misunderstood. Had the point of it been correctly recognised,
I think something might've been done about it then and there.

Perls going way back to god-knows-when are affected ... it's
not just blead.

The following is correct behaviour​:

#################################
C​:\>perl -Mwarnings -e "print 'xnan' + 0"
Argument "xnan" isn't numeric in addition (+) at -e line 1.
0
C​:\>perl -Mwarnings -e "print 'xinf' + 0"
Argument "xinf" isn't numeric in addition (+) at -e line 1.
0
#################################

However, for perls (such as my current build of 5.17.7) that
numify 'inf' and 'nan' strings to zero, the following is, IMO,
*not* right​:

#################################
C​:\>perl -Mwarnings -e "print 'nan' + 0"
0
C​:\>perl -Mwarnings -e "print 'inf' + 0"
0
#################################

The "isn't numeric" warning should still be present, but is
clearly missing.

It's as though we have, somewhere within the perl source, code
that says "don't issue a numeric warning if $str =~ /^nan/i".
I believe that conditional ought to be changed to "dont' issue a
numeric warning if $str =~ /^nan/i && 'nan' != 0".

And, similarly for 'inf' strings : Don't issue a numeric warning
if $str =~ /^inf/i && 'inf' != 0.

On perls built by this current compiler, I'm also getting (of
course)​:

#################################
C​:\>perl -Mwarnings -e "print 'NaN==NaN' if 'nan'=='nan'"
NaN==NaN
#################################

The immediate reaction to that is "OMG ... this perl thinks that
NaN == NaN !!"
That's not the case, of course - and if the numeric warning were
to appear, then there would be a better chance that the output
would be correctly assessed - which is, after all, the purpose of
these warnings in the first place.

For those curious as to why my perl numifies 'inf' and 'nan' to
zero, it seems that the mingw runtime of my current mingw.org
port of gcc (4.7.0) was built without INFNAN_CHECKS - which, I
gather is perfectly legitimate, though a little annoying.
Consequently its strtod() numifies 'inf' and 'nan' strings to 0,
and perl just follows suit.
(At least, that's AIUI.)

Cheers,
Rob

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.17.7:

Configured by sisyphus at Wed Dec 19 23:56:59 2012.

Summary of my perl5 (revision 5 version 17 subversion 7) configuration:

  Platform:
    osname=MSWin32, osvers=6.1, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=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='gcc', ccflags 
=' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 
 -fno-strict-aliasing -mms-bitfields',
    optimize='-s -O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='4.7.0', 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='long long', 
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags ='-s -L"c:\MinGW\bleadperl\lib\CORE" -L"C:\MinGW\lib"'
    libpth=C:\MinGW\lib C:\MinGW\msys\1.0\local\lib 
C:\MinGW\msys\1.0\local\ssl\lib
    libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 
 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion 
 -lodbc32 -lodbccp32 -lcomctl32
    perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 
 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion 
 -lodbc32 -lodbccp32 -lcomctl32
    libc=, so=dll, useshrplib=true, libperl=libperl517.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', 
lddlflags='-mdll -s -L"c:\MinGW\bleadperl\lib\CORE" -L"C:\MinGW\lib"'

Locally applied patches:



@INC for perl 5.17.7:
    C:/MinGW/bleadperl/site/lib
    C:/MinGW/bleadperl/lib
    .


Environment for perl 5.17.7:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\MinGW\bin;C:\MinGW\bleadperl\bin;C:\Program Files\Common 
Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common 
Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\NVIDIA 
Corporation\PhysX\Common;C:\Program Files (x86)\Intel\iCLS 
Client\;C:\Program Files\Intel\iCLS 
Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program 
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program 
Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files 
(x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files 
(x86)\Intel\Intel(R) Management Engine Components\IPT;C:\batch;C:\Program 
Files (x86)\Windows 
Live\Shared;C:\_32\dmake;C:\MinGW\msys\1.0\bin;C:\Program Files\Windows 
NT\Accessories;C:\zip
    PERL_BADLANG (unset)
    SHELL (unset) 

From @tonycoz

On Thu, Jan 03, 2013 at 08​:41​:05PM -0800, Sisyphus wrote​:

There was a bug report from a long time back about this.
It was closed a while ago and, since I couldn't find it to
re-open it, I've decided to to write a new report.
I think the closing of that report happened because it was
misunderstood. Had the point of it been correctly recognised,
I think something might've been done about it then and there.

Perls going way back to god-knows-when are affected ... it's
not just blead.

The following is correct behaviour​:

#################################
C​:\>perl -Mwarnings -e "print 'xnan' + 0"
Argument "xnan" isn't numeric in addition (+) at -e line 1.
0
C​:\>perl -Mwarnings -e "print 'xinf' + 0"
Argument "xinf" isn't numeric in addition (+) at -e line 1.
0
#################################

However, for perls (such as my current build of 5.17.7) that
numify 'inf' and 'nan' strings to zero, the following is, IMO,
*not* right​:

#################################
C​:\>perl -Mwarnings -e "print 'nan' + 0"
0
C​:\>perl -Mwarnings -e "print 'inf' + 0"
0
#################################

The "isn't numeric" warning should still be present, but is
clearly missing.

It's as though we have, somewhere within the perl source, code
that says "don't issue a numeric warning if $str =~ /^nan/i".
I believe that conditional ought to be changed to "dont' issue a
numeric warning if $str =~ /^nan/i && 'nan' != 0".

What does your compiler/runtime produce when outputting NaN/INF?

eg. strawberry perl produces​:

C​:\Users\tony\dev\perl\git>perl -le "print +(-1)**0.5"
1.#QNAN

C​:\Users\tony\dev\perl\git>perl -le "print 2**100000"
1.#INF

I suspect we should either​:

a) consistently stringify NaN and Inf (and their variations) on all
platforms, and consistently numify their string representations.

or

b) disable the warning for the platform specific representations, and
ensure those platform specific representations are numified correctly
- the Win32 versions above aren't​:

C​:\Users\tony\dev\perl\git>perl -le "print '1.#INF'+'1.#INF'"
2

While they are on Linux​:

tony@​mars​:.../git/bse$ perl -le 'print "inf"+"inf"'
inf
tony@​mars​:.../git/bse$ perl -le 'print "inf"+"nan"'
nan
tony@​mars​:.../git/bse$ perl -le 'print "inf"+1'
inf
tony@​mars​:.../git/bse$ perl -le 'print "nan"+1'
nan

Tony

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

From @sisyphus

-----Original Message-----
From​: Tony Cook
Sent​: Friday, January 04, 2013 4​:20 PM

The following is correct behaviour​:

#################################
C​:\>perl -Mwarnings -e "print 'xnan' + 0"
Argument "xnan" isn't numeric in addition (+) at -e line 1.
0
C​:\>perl -Mwarnings -e "print 'xinf' + 0"
Argument "xinf" isn't numeric in addition (+) at -e line 1.
0
#################################

However, for perls (such as my current build of 5.17.7) that
numify 'inf' and 'nan' strings to zero, the following is, IMO,
*not* right​:

#################################
C​:\>perl -Mwarnings -e "print 'nan' + 0"
0
C​:\>perl -Mwarnings -e "print 'inf' + 0"
0
#################################

The "isn't numeric" warning should still be present, but is
clearly missing.

It's as though we have, somewhere within the perl source, code
that says "don't issue a numeric warning if $str =~ /^nan/i".
I believe that conditional ought to be changed to "dont' issue a
numeric warning if $str =~ /^nan/i && 'nan' != 0".

What does your compiler/runtime produce when outputting NaN/INF?

In a C program, a NaN will be output as either 1.#QNAN or 1.#IND. (And
sometimes those symbols can be prefixed with a minus sign, IIRC. I forget
the rules ... and probably never understood them anyway.)
An INF will be output as 1.#INF (-1.#INF for minus infinity).
I regard these as quite correct for Windows.

eg. strawberry perl produces​:

C​:\Users\tony\dev\perl\git>perl -le "print +(-1)**0.5"
1.#QNAN

C​:\Users\tony\dev\perl\git>perl -le "print 2**100000"
1.#INF

For my Strawberry Perl (5.16.0)​:

C​:\_32\strawberry516>perl -le "print +(-1)**0.5"
-1.#IND

C​:\_32\strawberry516>perl -le "print 2**100000"
1.#INF

I suspect we should either​:

a) consistently stringify NaN and Inf (and their variations) on all
platforms, and consistently numify their string representations.

or

b) disable the warning for the platform specific representations, and
ensure those platform specific representations are numified correctly
- the Win32 versions above aren't​:

C​:\Users\tony\dev\perl\git>perl -le "print '1.#INF'+'1.#INF'"
2

That doesn't bother me. I think it quite reasonable that the string '1.#INF'
should numify to 1.

What Strawberry also does of course is​:

C​:\_32\strawberry516>perl -e "print 'nan' + 0"
-1.#IND
C​:\_32\strawberry516>perl -le "print 'inf' + 0"
1.#INF

C​:\_32\strawberry516>perl -le "print 'nan' + 0"
-1.#IND

C​:\_32\strawberry516>

Obviously, the mingw runtime of the gcc compiler that builds Strawberry
*was* built with INFNAN_CHECKS.

While they are on Linux​:

tony@​mars​:.../git/bse$ perl -le 'print "inf"+"inf"'
inf
tony@​mars​:.../git/bse$ perl -le 'print "inf"+"nan"'
nan
tony@​mars​:.../git/bse$ perl -le 'print "inf"+1'
inf
tony@​mars​:.../git/bse$ perl -le 'print "nan"+1'
nan

With Strawberry, the same happens - except that the inf/nan output is
written in the Windows-specific form.
With the perls I've built using the gcc-4.7.0 compiler that I grabbed from
mingw.org, however, the output is quite different because the "inf" and
"nan" strings get evaluated to 0.
I've no problem with any of that - and wasn't really trying to get inot a
debate upon just how INF/NaN ought to display.

I just think that when (and only when) perl numifies "nan" and "inf" strings
to 0, the numeric warning should be given whenever such strings are used in
numeric context.
That's not happening. Instead there's apparently a blanket approach of
universally suppressing numeric warnings for "inf" and "nan" strings that
get used in numeric context.

I'm not asking for what you've provided as options a) and b) ... it would
probably confuse me for a while, and break numerous pieces of existing
code... but in the long run, I reckon I'd adapt and benefit, though I'm not
sure that all others would be so amenable.
(Implementing such changes would, I imagine, be far from trivial.)

Cheers,
Rob

From @tonycoz

On Thu, Jan 03, 2013 at 08​:41​:05PM -0800, Sisyphus wrote​:

There was a bug report from a long time back about this.
It was closed a while ago and, since I couldn't find it to
re-open it, I've decided to to write a new report.
I think the closing of that report happened because it was
misunderstood. Had the point of it been correctly recognised,
I think something might've been done about it then and there.

I see two reports from you on related issues: #8036 and #8377

Tony