Unfortunately this latest commit (4ac6fab20b8950ee14756c6f2438809c572082cd) gets us back to assigning values incorrectly. (Perl's test suite will not presently detect this.) I guess we've now somehow gone back to using perl's atof() function for assignment of floating point values. At least, it seems that the values being assigned are now the same as the values that perl's atof() assigns. A quick check that will catch the problem is to run something like: $ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != 8.87359152e-6;' When nvtype is 'double, the value of 8.87359152e-6 is assigned incorrectly by perl's atof on a number of platforms, including Windows and Linux - so it's a good value to test. Perhaps we should even add that test to the POSIX test suite ? We'd need to test a different value for -Duselongdouble builds - I'll write a patch for posix.t and submit it later today in a separate bug report. That way, if Perl_strtod() is defined but perl's atof() is being used, we'd find out about it when perl's test suite is run. Cheers, Rob On Tue, Apr 16, 2019 at 7:53 AM Karl Williamson via RT < perlbug-followup@perl.org> wrote: > This should be fixed by > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > Author: Karl Williamson <khw@cpan.org> > Date: Mon Apr 15 11:10:31 2019 -0600 > > PATCH: [perl #133945] Perl_strtod failures > > This commit wraps Perl_strtod() in macros that cause the proper radix > character to be used. > > -- > Karl Williamson > > --- > via perlbug: queue: perl5 status: open > https://rt.perl.org/Ticket/Display.html?id=133945 >Thread Previous | Thread Next