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