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 13:06
Subject:
Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372breaksfloat formatting under GTK
Message ID:
CADZSBj1fLxoD5HB4ErP+j8pkXiGS-zWdjU392PiaCFu+285XcQ@mail.gmail.com
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.)

Cheers,
Rob


On Tue, Apr 16, 2019 at 10:26 PM sisyphus <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> 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