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

Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372breaksfloat formatting under GTK

Thread Previous | Thread Next
From:
sisyphus
Date:
April 16, 2019 12:27
Subject:
Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372breaksfloat formatting under GTK
Message ID:
CADZSBj0gs+33q-YMEb2Q35x7Z0WTVc7Tv1rxCxGUjZ5DonxRsQ@mail.gmail.com
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> 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.
>
>
> > 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


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