text->float conversion gives wrong answer

[p5pRT]

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

Searchable as RT41202$

[p5pRT]

From zefram@fysh.org

Created by zefram@fysh.org

$ perl -lwe 'printf "%f\n", 1180591620717411303424.0'
1180591620717411172352.000000
$

The value that I put in the source is exactly 2^70. This is
trivially representable as a native float. The value that is printed
out is 2^70-2^17, which is the *next lower* floating-point value.
(The significand has 52 fractional bits; this value has exponent 69 and
all significand bits set.) 2^70-2^17 itself converts just fine​:

$ perl -lwe 'printf "%f\n", 1180591620717411172352.0'
1180591620717411172352.000000
$

Using that I can construct 2^70, which converts back to text normally​:

$ perl -lwe 'printf "%f\n", 1180591620717411172352.0+131072.0'
1180591620717411303424.000000
$

For further evidence that it is the text->float conversion, and not
float->text, that is in error, one can use my Data​::Float module to
display the actual bit pattern​:

$ perl -MData​::Float=float_hex -lwe 'print float_hex(1180591620717411303424.0)'
+0x1.fffffffffffffp+69
$ perl -MData​::Float=float_hex -lwe 'print float_hex(1180591620717411172352.0+131072.0)'
+0x1.0000000000000p+70
$

The same conversion fault occurs with runtime string->number conversion
also.

This fault does not occur with other programs doing this conversion on
the same machine​:

zsh% echo $((1180591620717411303424.0 == 1180591620717411172352.0))
0
zsh% echo $((1180591620717411303424.0-131072.0 == 1180591620717411172352.0))
1
zsh%

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.4:

Configured by Debian Project at Wed May 10 04:14:05 UTC 2006.

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
  Platform:
    osname=linux, osvers=2.6.15.6, archname=i386-linux-thread-multi
    uname='linux ernie 2.6.15.6 #1 thu mar 16 13:11:55 est 2006 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.4 -Dsitearch=/usr/local/lib/perl/5.8.4 -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.4 -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='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-13)', 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.4
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.4:
    /etc/perl
    /usr/local/lib/perl/5.8.4
    /usr/local/share/perl/5.8.4
    /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.4:
    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
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

[p5pRT]

From @cpansprout

On Sun Jan 07 10​:45​:52 2007, zefram@​fysh.org wrote​:

$ perl -lwe 'printf "%f\n", 1180591620717411303424.0'
1180591620717411172352.000000
$

The value that I put in the source is exactly 2^70.

Perl’s atof implementation (c2988b2) multiplies by ten every time it
scans a new digit. This results in loss of precision. What is the best
way to tell whether an NV differs from the PV it was derived from?
Running it through sprintf internally seems like a bit much.

[p5pRT]

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

[p5pRT]

From @samv

On Sun Nov 28 14​:44​:28 2010, sprout wrote​:

On Sun Jan 07 10​:45​:52 2007, zefram@​fysh.org wrote​:

$ perl -lwe 'printf "%f\n", 1180591620717411303424.0'
1180591620717411172352.000000
$

The value that I put in the source is exactly 2^70.

Perl’s atof implementation (c2988b2) multiplies by ten every time it
scans a new digit. This results in loss of precision. What is the best
way to tell whether an NV differs from the PV it was derived from?
Running it through sprintf internally seems like a bit much.

I performed some investigation of this "bug". No precision is lost by
multiplying a small integer in a float by 10. You can see how close it
is to being correct from the binary representation​:

perl -le 'print unpack("H*", reverse(pack("d",
1180591620717411303424.0)))'
444fffffffffffff

This is 1.fffffffffffff * 2^69 and a valid conversion for the input
according to at least ieee754-2008 and C99.

It seems true that C99 encourages implementations to perform "correct"
rounding, that is, returning the binary value which is closest to the
input value. However this is just wishful thinking - actual
implementation requires MP math; you need to convert the entire input
value at whatever precision it is given, to a binary value of at least
55 or so bits wide. And then apply the rounding rules in binary to find
out what the "correct" value is. So there are "halfway points", the
values above are one binary value and the values below are another. If
the input decimal number matches one of these halfway points exactly,
then you have to process some pretty big numbers.

As to how glibc gets it "right". I pulled apart the glibc and indeed
some "clever" person actually tried to take the advice in C99 literally;
strtod uses GMP internally to try to get this right. Yes, GMP.

But it still gets it wrong​:

http​://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-
and-glibc/

This is apparently because the glibc strtod has a "pragmatic" limit of
something like 10 extra decimal digits before deciding to ignore the
rest. Even that is incorrect, as the writers in the above article note,
the worst case is over 700 decimal digits of precision that must be
calculated before the final answer can be known.

So they just made a string to number conversion not only use MP math and
so be very slow, but they didn't even get the "perfect" behaviour they
were seeking. "Excessive cleverness"

Practically speaking, Perl's implementation is about as good as you
could expect from a high performance solution and as far as I can tell
confirms to ieee754 rules. If you want the over-engineered version in
glibc, then build your Perl with d_strtod=1 or use a CPAN module which
implements the semantics you are after.

I suggest setting this ticket to 'rejected'

[p5pRT]

From zefram@fysh.org

Tom Hukins has run into an interesting case of this bug. He's trying
to port Perl to the Beaglebone Black dev board, which is based on an
ARMv6 processor and turns out to have some floating-point oddities.
Tom commented "I believe the OS uses software floating point ATM but
plans to move over to hardware at some point". The more legitimate of
its oddities is that it doesn't support subnormal values. It turns out
that this causes the "min double" test in opbasic/arith.t to fail​:

  try $T++, 2.2250738585072014e-308 != 0.0, 'min double';

The value shown is not particularly close to the minimum IEEE
double-precision value (which is about 4.94e-324, 2**-1074). It's trying
to get the minimum *normal* IEEE double-precision value, 2**-1022.
The decimal value in the test is fractionally above that. Because the
Beaglebone system does use IEEE double parameters, this test is looking at
a relevant threshold​: 2**-1022 is not merely its minimum positive normal
value, but actually its minimum positive value overall. In theory the
test should pass. (The test is arguably bogus because we don't otherwise
require any particular FP range, but that's a separate issue.)

However, the duff decimal->float conversion has the effect of breaking
the decimal up into a bunch of single-digit subvalues to sum, all of
which in this case are necessarily below the range of normal FP values.
On a full IEEE system, the first few are representable as subnormals,
but eventually they're not representable at all, and the conversion
gets truncated, quite aside from the rounding error. (But actually,
after the first digit they're not even converted to subnormals, but
instead are erroneously treated as zero; ISTR this being reported as
a separate bug somewhere. So overall the test value is converted as
if it were only 2.0e-308, and comes out as a subnormal value that is
proportionally quite a lot lower than the proper value.) It's still
non-zero, so the test passes.

On the Beaglebone, because subnormals can't be handled at all, all of
the single-digit subvalues are computed as zero, and so the sum is zero.
So the test fails, even though the value the test intends to try is
representable distinct from zero.

-zefram

[p5pRT]

From @sisyphus

Le Tue, 01 Feb 2011 16​:10​:13 -0800, mugwump a écrit :
[snip]

If you want the over-engineered version in
glibc, then build your Perl with d_strtod=1

This is 7 years later, and even when HAS_STRTOD is defined with the latest devel release(perl-5.27.9) we don't get the value that glibc assigns.
And the value we do get is often wrong by more than just one ulp.

I noticed quite some time ago that, with -Dusequadmath builds of perl, there are not any known cases of perl assigning a floating point value incorrectly.
I'm not saying that all values are assigned correctly on -Dusequadmath builds - merely that I haven't been able to find any incorrect assignments on -Dusequadmath builds.

In contrast, it's amazingly easy to hit floating point values on double and (extended precision) long double builds of perl that are assigned incorrectly.

So ... what's so special about the way that the quadmath builds assign values ?
AFAICT, the quadmath builds always assign the value that Perl_strtod() returns.
But on the 'double' and 'long double' builds, the (nearly always correct) value returned by Perl_strtod() is ignored in preference to the often incorrect value returned by perl's bodgey atof calculations.

Now, it seems to me that if Perl_strtod() is good enough for quadmath builds, then it ought to be good enough for 'double' and 'long double' builds, too.
So, on Windows and Ubuntu, I tried a simplistically patched numeric.c that achieved that - and with strikingly improved results for perl-5.27.9.

The patch (attached) ensures that, if Perl_strtod is defined, assignment of values for 'double' and 'long double' builds of perl follows the same path as that for '__float128' builds.
For me, Perl_strtod is defined by default on Ubuntu and MS Windows. If Perl_strtod is not defined, then the patch should have no effect.
(Note that perl.h unconditionally defines Perl_strtod to strtoflt128 if USE_QUADMATH is defined.)

The main script I've used for testing is nv2.pl (attached).

On an *unpatched* 5.27.9, running 'perl nv2.pl 10' has always quickly hit a mis-assigned value (mostly within the first 20 iterations) and died.
On the various *patched* builds of 5.27.9 that I've tested, it has always run the full 1 million iterations without producing any output.
Of course, on the patched builds, Perl_strtod and C's strtod/strtold/strtoflt128 are the same function, so it's totally expected that the script will not die when run.
What's important, however, is that the complete absence of warnings indicates that the assigned values are also correct.

I have managed to find some instances where strtod/strtold does return an incorrect value, but only on a targeted search of values close to a power of 2.
Clearly these are libc bugs - and they are comparatively very rare. I know of only 1 such value on Ubuntu, and 3 on Windows.
As regards quadmath builds, I haven't found any instances of strtoflt128 assigning incorrectly.

With the patched numeric.c, all tests still passed on x86 windows for both 'double' and 'long double' builds.(Can't do quadmath builds on Windows.)

Annoyingly, on the Windows 'long double' build only, the patch altered the way that the numification of the string '9875'x1000 alters the internals. (This caused one Math​::MPFR test to fail, and I need to investigate it.)

On Ubuntu, patched builds produce the following test failure for both the 'double' and the 'long double' build​:

t/porting/args_assert ..........................................
# Failed test 2 - PERL_ARGS_ASSERT_GROK_ATOUV is declared but not used at porting/args_assert.t line 62
# Failed test 3 - PERL_ARGS_ASSERT_GROK_BIN is declared but not used at porting/args_assert.t line 62
# Failed test 4 - PERL_ARGS_ASSERT_GROK_HEX is declared but not used at porting/args_assert.t line 62
# Failed test 5 - PERL_ARGS_ASSERT_GROK_INFNAN is declared but not used at porting/args_assert.t line 62
# Failed test 6 - PERL_ARGS_ASSERT_GROK_NUMBER is declared but not used at porting/args_assert.t line 62
# Failed test 7 - PERL_ARGS_ASSERT_GROK_NUMBER_FLAGS is declared but not used at porting/args_assert.t line 62
# Failed test 8 - PERL_ARGS_ASSERT_GROK_NUMERIC_RADIX is declared but not used at porting/args_assert.t line 62
# Failed test 9 - PERL_ARGS_ASSERT_GROK_OCT is declared but not used at porting/args_assert.t line 62
# Failed test 10 - PERL_ARGS_ASSERT_ISINFNANSV is declared but not used at porting/args_assert.t line 62
# Failed test 11 - PERL_ARGS_ASSERT_MY_ATOF is declared but not used at porting/args_assert.t line 62
# Failed test 12 - PERL_ARGS_ASSERT_MY_ATOF2 is declared but not used at porting/args_assert.t line 62
# Failed test 13 - PERL_ARGS_ASSERT_SCAN_BIN is declared but not used at porting/args_assert.t line 62
# Failed test 14 - PERL_ARGS_ASSERT_SCAN_HEX is declared but not used at porting/args_assert.t line 62
# Failed test 15 - PERL_ARGS_ASSERT_SCAN_OCT is declared but not used at porting/args_assert.t line 62
FAILED at test 2

Other than that, all seems fine.

Is any of this at all useful ?
If so, I'll continue to look for creases, with an aim to getting them out.

Cheers,
Rob

[p5pRT]

From @sisyphus

nv2.pl

[p5pRT]

From @sisyphus

Hmmm ... I don't see the patch.
Resending it.

[p5pRT]

From @sisyphus

--- numeric.c_orig 2018-03-07 19​:31​:23 +1100
+++ numeric.c 2018-03-10 14​:28​:53 +1100
@​@​ -1107,7 +1107,7 @​@​
  return TRUE;
}

-#ifndef USE_QUADMATH
+#ifndef Perl_strtod
STATIC NV
S_mulexp10(NV value, I32 exponent)
{
@​@​ -1203,7 +1203,7 @​@​
  }
  return negative ? value / result : value * result;
}
-#endif /* #ifndef USE_QUADMATH */
+#endif /* #ifndef Perl_strtod */

NV
Perl_my_atof(pTHX_ const char* s)
@​@​ -1214,7 +1214,7 @​@​

  PERL_ARGS_ASSERT_MY_ATOF;

-#ifdef USE_QUADMATH
+#ifdef Perl_strtod

  Perl_my_atof2(aTHX_ s, &x);

@​@​ -1357,11 +1357,11 @​@​
{
  const char* s = orig;
  NV result[3] = {0.0, 0.0, 0.0};
-#if defined(USE_PERL_ATOF) || defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) || defined(Perl_strtod)
  const char* send = s + strlen(orig); /* one past the last */
  bool negative = 0;
#endif
-#if defined(USE_PERL_ATOF) && !defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) && !defined(Perl_strtod)
  UV accumulator[2] = {0,0}; /* before/after dp */
  bool seen_digit = 0;
  I32 exp_adjust[2] = {0,0};
@​@​ -1374,7 +1374,7 @​@​
  I32 sig_digits = 0; /* noof significant digits seen so far */
#endif

-#if defined(USE_PERL_ATOF) || defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) || defined(Perl_strtod)
  PERL_ARGS_ASSERT_MY_ATOF2;

  /* leading whitespace */
@​@​ -1391,12 +1391,12 @​@​
  }
#endif

-#ifdef USE_QUADMATH
+#ifdef Perl_strtod
  {
  char* endp;
  if ((endp = S_my_atof_infnan(aTHX_ s, negative, send, value)))
  return endp;
- result[2] = strtoflt128(s, &endp);
+ result[2] = Perl_strtod(s, &endp);
  if (s != endp) {
  *value = negative ? -result[2] : result[2];
  return endp;

[p5pRT]

From @sisyphus

Le Fri, 09 Mar 2018 22​:47​:01 -0800, sisyphus a écrit :

Annoyingly, on the Windows 'long double' build only, the patch altered
the way that the numification of the string '9875'x1000 alters the
internals. (This caused one Math​::MPFR test to fail, and I need to
investigate it.)

Looks to me like a mingw runtime bug in strtold() - which I've reported to​:
https://sourceforge.net/p/mingw-w64/bugs/711/

Cheers,
Rob

[p5pRT]

From @sisyphus

On Sun, 11 Mar 2018 04​:11​:50 -0700, sisyphus wrote​:

Le Fri, 09 Mar 2018 22​:47​:01 -0800, sisyphus a écrit :

Annoyingly, on the Windows 'long double' build only, the patch altered
the way that the numification of the string '9875'x1000 alters the
internals. (This caused one Math​::MPFR test to fail, and I need to
investigate it.)

Looks to me like a mingw runtime bug in strtold() - which I've reported to​:
https://sourceforge.net/p/mingw-w64/bugs/711/

The bug turns out to be easily worked around. Attached is the patch I eventually used with perl-5.28.0.
On the systems I've tested, it works flawlessly and I've yet to find a value that gets assigned incorrectly on either "double" builds or extended precision "long double" builds or "__float128" builds of perl.
It also does not cause any of the tests (in the perl-5.28.0 test suite) to fail.

The systems I've tested have been Ubuntu-16.04 (gcc-5.4.0 &, glibc-2.23), Debian Wheezy (gcc-4.6.3 & glibc-2.13) and MS Windows (various mingw-w64 ports of gcc-4.7.0 thru to 8.1.0).

I'm therefore unaware of any valid reason that this modified patch should not be incorporated into perl-5.29.
If objections exist, please raise them so that I can attend to them.

The effects of this patch can be nullified by building perl such that HAS_STRTOD or HAS_STRTOLD is not defined. On Linux this is as simple as configuring the perl build with -Ud_strtod or -Ud_strtold.

I've given a little more detail at https://www.perlmonks.org/?node_id=1217588

Cheers,
Rob

[p5pRT]

From @sisyphus

--- numeric.c_orig 2018-07-01 21​:44​:17 +1000
+++ numeric.c 2018-07-01 12​:49​:47 +1000
@​@​ -1119,7 +1119,7 @​@​
  return TRUE;
}

-#ifndef USE_QUADMATH
+#ifndef Perl_strtod
STATIC NV
S_mulexp10(NV value, I32 exponent)
{
@​@​ -1215,7 +1215,7 @​@​
  }
  return negative ? value / result : value * result;
}
-#endif /* #ifndef USE_QUADMATH */
+#endif /* #ifndef Perl_strtod */

NV
Perl_my_atof(pTHX_ const char* s)
@​@​ -1226,7 +1226,7 @​@​

  PERL_ARGS_ASSERT_MY_ATOF;

-#ifdef USE_QUADMATH
+#ifdef Perl_strtod

  Perl_my_atof2(aTHX_ s, &x);

@​@​ -1369,11 +1369,11 @​@​
{
  const char* s = orig;
  NV result[3] = {0.0, 0.0, 0.0};
-#if defined(USE_PERL_ATOF) || defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) || defined(Perl_strtod)
  const char* send = s + strlen(orig); /* one past the last */
  bool negative = 0;
#endif
-#if defined(USE_PERL_ATOF) && !defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) && !defined(Perl_strtod)
  UV accumulator[2] = {0,0}; /* before/after dp */
  bool seen_digit = 0;
  I32 exp_adjust[2] = {0,0};
@​@​ -1386,7 +1386,7 @​@​
  I32 sig_digits = 0; /* noof significant digits seen so far */
#endif

-#if defined(USE_PERL_ATOF) || defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) || defined(Perl_strtod)
  PERL_ARGS_ASSERT_MY_ATOF2;

  /* leading whitespace */
@​@​ -1403,12 +1403,27 @​@​
  }
#endif

-#ifdef USE_QUADMATH
+#ifdef Perl_strtod
  {
  char* endp;
  if ((endp = S_my_atof_infnan(aTHX_ s, negative, send, value)))
  return endp;
- result[2] = strtoflt128(s, &endp);
+# if defined(__MINGW64_VERSION_MAJOR) && defined(USE_LONG_DOUBLE)
+
+ /***********************************************
+ We are unable to use strtold because of
+ https://sourceforge.net/p/mingw-w64/bugs/711/
+ &
+ https://sourceforge.net/p/mingw-w64/bugs/725/
+
+ but __mingw_strtold is fine.
+ ***********************************************/
+
+ result[2] = __mingw_strtold(s, &endp);
+
+# else
+ result[2] = Perl_strtod(s, &endp);
+# endif
  if (s != endp) {
  *value = negative ? -result[2] : result[2];
  return endp;

[p5pRT]

From @jkeenan

On Sat, 14 Jul 2018 12​:22​:08 GMT, sisyphus@​cpan.org wrote​:

The bug turns out to be easily worked around. Attached is the patch I
eventually used with perl-5.28.0.

numeric.c has changed since perl-5.28.0, so your patch did not apply cleanly. There were 3 hunks rejected, preventing me from creating a smoke-me branch for testing.

Would it be possible to re-draw this patch against perl 5 blead, preferably creating the patch with 'git format-patch'?

Thank you very much.

Cheers,
Rob

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

[p5pRT]

From @sisyphus

And, of course, when I incorporate my patch into the current blead version
of numeric.c I find that re/uniprops02.t and re/uniprops03.t both fail a
number of tests. All other tests pass.
All that my patch does is to make "double" and "long double" builds follow
the same path through numeric.c as that taken by the "_float128" builds -
and it therefore comes as no surprise that the "__float128" builds
(-Dusequadmath), built using the official (ie unpatched) numeric.c also
fail those same 2 test scripts.
(I'll notify p5p of this breakage shortly.)

So ... I think I'll wait for this issue with the quadmath builds to be
resolved before investigating further. I'm quietly confident that when that
problem with the quadmath builds gets fixed, then so does the problem with
my patch.

The actual patch I used with latest blead (commit 76416d1) is attached.

It would be great if we could have my patch smoked - though perhaps it
would be pertinent to wait for the current broken state of blead (wrt
quadmath builds) to be fixed.

Thanks for showing some interest, Jim. It's much appreciated !

Cheers,
Rob

On Sun, Jul 15, 2018 at 9​:21 AM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

On Sat, 14 Jul 2018 12​:22​:08 GMT, sisyphus@​cpan.org wrote​:

The bug turns out to be easily worked around. Attached is the patch I
eventually used with perl-5.28.0.

numeric.c has changed since perl-5.28.0, so your patch did not apply
cleanly. There were 3 hunks rejected, preventing me from creating a
smoke-me branch for testing.

Would it be possible to re-draw this patch against perl 5 blead,
preferably creating the patch with 'git format-patch'?

Thank you very much.

Cheers,
Rob

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

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=41202

[p5pRT]

From @sisyphus

0001-patched-numeric.c.patch

From 53be06c206a17fea83599e7607ca72d8d2d2d7c3 Mon Sep 17 00:00:00 2001
From: sisyphus <sisyphus1@optusnet.com.au>
Date: Sun, 15 Jul 2018 11:39:59 +1000
Subject: [PATCH] patched numeric.c

---
 numeric.c | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/numeric.c b/numeric.c
index 34eb8b3..9f98311 100644
--- a/numeric.c
+++ b/numeric.c
@@ -1143,7 +1143,7 @@ Perl_grok_atoUV(const char *pv, UV *valptr, const char** endptr)
     return TRUE;
 }
 
-#ifndef USE_QUADMATH
+#ifndef Perl_strtod
 STATIC NV
 S_mulexp10(NV value, I32 exponent)
 {
@@ -1239,7 +1239,7 @@ S_mulexp10(NV value, I32 exponent)
     }
     return negative ? value / result : value * result;
 }
-#endif /* #ifndef USE_QUADMATH */
+#endif /* #ifndef Perl_strtod */
 
 NV
 Perl_my_atof(pTHX_ const char* s)
@@ -1250,7 +1250,7 @@ Perl_my_atof(pTHX_ const char* s)
 
     PERL_ARGS_ASSERT_MY_ATOF;
 
-#ifdef USE_QUADMATH
+#ifdef Perl_strtod
 
     my_atof2(s, &x);
 
@@ -1400,13 +1400,13 @@ Perl_my_atof3(pTHX_ const char* orig, NV* value, STRLEN len)
 {
     const char* s = orig;
     NV result[3] = {0.0, 0.0, 0.0};
-#if defined(USE_PERL_ATOF) || defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) || defined(Perl_strtod)
     const char* send = s + ((len != 0)
                            ? len
                            : strlen(orig)); /* one past the last */
     bool negative = 0;
 #endif
-#if defined(USE_PERL_ATOF) && !defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) && !defined(Perl_strtod)
     UV accumulator[2] = {0,0};	/* before/after dp */
     bool seen_digit = 0;
     I32 exp_adjust[2] = {0,0};
@@ -1419,7 +1419,7 @@ Perl_my_atof3(pTHX_ const char* orig, NV* value, STRLEN len)
     I32 sig_digits = 0; /* noof significant digits seen so far */
 #endif
 
-#if defined(USE_PERL_ATOF) || defined(USE_QUADMATH)
+#if defined(USE_PERL_ATOF) || defined(Perl_strtod)
     PERL_ARGS_ASSERT_MY_ATOF3;
 
     /* leading whitespace */
@@ -1436,13 +1436,28 @@ Perl_my_atof3(pTHX_ const char* orig, NV* value, STRLEN len)
     }
 #endif
 
-#ifdef USE_QUADMATH
+#ifdef Perl_strtod
     {
         char* endp;
         if ((endp = S_my_atof_infnan(aTHX_ s, negative, send, value)))
             return endp;
         endp = send;
-        result[2] = strtoflt128(s, &endp);
+#  if defined(__MINGW64_VERSION_MAJOR) && defined(USE_LONG_DOUBLE)
+
+        /***********************************************
+         We are unable to use strtold because of
+          https://sourceforge.net/p/mingw-w64/bugs/711/
+          &
+          https://sourceforge.net/p/mingw-w64/bugs/725/
+
+         but __mingw_strtold is fine.
+         ***********************************************/
+
+        result[2] = __mingw_strtold(s, &endp);
+
+#  else
+        result[2] = Perl_strtod(s, &endp);        
+#  endif
         if (s != endp) {
             *value = negative ? -result[2] : result[2];
             return endp;
-- 
2.1.4