On 4/15/19 8:39 PM, sisyphus wrote: > 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. I re-inspected the patch and don't see anyway that it could have made this switcheroo. > > 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 sounds good. > 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 <mailto:perlbug-followup@perl.org>> wrote: > > This should be fixed by > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > Author: Karl Williamson <khw@cpan.org <mailto: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