develooper Front page | perl.perl5.porters | Postings from April 2019

Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK

Thread Previous | Thread Next
From:
sisyphus
Date:
April 16, 2019 08:53
Subject:
Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK
Message ID:
CADZSBj1KYUz316o76NxTURS=HAoj1RRcMaa0tqAp5eLWnjUcoQ@mail.gmail.com
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();
########################

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>
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>> 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About