Front page | perl.perl5.porters |
Postings from April 2019
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