On 4/16/19 7:06 AM, sisyphus wrote: > > I see that line 6555 of perl.h is presently: > #define Perl_strotod(s, e) \ > > I wonder if that was meant to be: > #define Perl_strtod(s, e) \ > > (I'll test it.) Yes, that's the typo. But fixing it opens a can of worms. Which I believe I have fixed in https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-strtod Please check it out. > > Cheers, > Rob > > > On Tue, Apr 16, 2019 at 10:26 PM sisyphus <sisyphus359@gmail.com > <mailto:sisyphus359@gmail.com>> wrote: > > James, > Does the following behave as desired ? > > ##################### > use warnings; > use Inline C => <<'EOC'; > int foo() { > #ifdef Perl_strtod > return 0; > #else > return 1; > #endif > } > EOC > exit(foo()); > #################### > > Cheers, > Rob > > On Tue, Apr 16, 2019 at 9:59 PM James E Keenan <jkeenan@pobox.com > <mailto:jkeenan@pobox.com>> wrote: > > 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 > <http://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> > > <mailto: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>> > > <mailto: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>> > > <mailto: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