Front page | perl.perl5.porters |
Postings from April 2019
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.
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 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> wrote:
> This should be fixed by
> commit 4ac6fab20b8950ee14756c6f2438809c572082cd
> Author: Karl Williamson <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