On 4/16/19 4:53 AM, sisyphus wrote: > Something in the last couple of days has definitely caused a reversion > to use of perl's atof(). > > This Inline::C script: > ######################## > use warnings; > use Inline C => <<'EOC'; > void foo() { > #ifdef Perl_strtod > printf("Perl_strtod defined\n"); > #else > printf("Perl_strtod NOT defined\n"); > #endif > } > EOC > foo(); > ######################## > I can confirm this result on Linux. Is there any way your C program could be rewritten such that we get a Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had that, then we could plug it into Porting/bisect.pl. > reports (on all of my Windows and Linux builds) that current blead has > Perl_strtod NOT defined. > If Perl_strtod is not defined then I don't think that Perl_strtod can be > assigning the values - it must surely be perl's atof() that's doing the > assigning. > > My -Dusequadmath builds are also afflicted with the issue (as they now > also do not define Perl_strtod). That's not a reversion - this is the > first time ever that quadmath builds have used perl's atof(), and the > result is not pretty. > > Anyway - perhaps it's not your commit that's the culprit. > It has to be something fairly recent because I built blead a couple of > days ago and it was fine. (My builds do check that > strtod/strtold/strtoflt128 are being used.) > I haven't even yet glanced at the current perl source. I've instead been > trying to gauge the scope of the breakage - which is something that took > me far longer than it ought. > > I'll prepare and post that patch to posix.t tonight, and try to get my > head around the perl source tomorrow. > > Cheers, > Rob > > On Tue, Apr 16, 2019 at 1:50 PM Karl Williamson <public@khwilliamson.com > <mailto:public@khwilliamson.com>> wrote: > > 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> > <mailto: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> > <mailto: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