develooper Front page | perl.perl5.porters | Postings from August 2018

[perl #41202] text->float conversion gives wrong answer

Thread Previous | Thread Next
From:
sisyphus@cpan.org via RT
Date:
August 1, 2018 01:07
Subject:
[perl #41202] text->float conversion gives wrong answer
Message ID:
rt-4.0.24-15910-1533085645-681.41202-15-0@perl.org
On Thu, 26 Jul 2018 06:37:30 -0700, sisyphus@cpan.org wrote:
> Just found another couple of spots (one in embed.h, one in proto.h)
> where s/USE_QUADMATH/Perl_strtod/ ought to be done.

I've since made those changes to proto.h and embed.h. I think they do no more than silence a couple of compiler warnings. I also had to move the Perl_strtod definitions a bit close to the start of perl.h - otherwise embed.h and proto.h are included before Perl_strtod was defined.

The changes cause porting/regen.t to fail tests 37 and 38 because (respectively) proto.h and embed.h have changed - not that there's anything wrong with those changes.
How do I make my alterations to embed.h and proto.h without being subjected to such failures ?

And I now also get (on Linux) porting/args_assert.t failures about symbols that were declared but not used.
Can I take it as gospel that those symbols were in fact "declared but not used" - or might it simply be that args_assert.t requires some alterations ?

> I don't know whether that will account for the lib/locale.t failures,

It doesn't.
Those failures can best be demonstrated by running the following on a perl whose locale radix character is a comma:

use warnings;
use locale;
$m = "3.14e+9" + 0;
$n = "3,14e+9" + 0;
print "\$m is $m\n";
print "\$n is $n\n";
__END__

 On recent perls and current bleadperl (non-quadmath builds) it outputs:
$m is 3140000000
$n is 3140000000

But with my patched perl it outputs
$m is 3140000000
$n is 3

The problem appears to be that, although perls Atof takes the locale radix character into account, Perl_strtod does not.
Quadmath builds of perl (which use Perl_strtod) avoid these failures by skipping the (5) tests that would otherwise fail. The same approach also works fine for my patched "double" and "long double" builds - though I wonder if such a concealment of a change of behaviour might be frowned upon ;-)

Which of the issues just mentioned need to be fixed before my proposed changes to perl.h, numeric.c, embed.h, and proto.h can be applied to perl.

Attached are the latest patches


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=41202

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