New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stringifying NaN and Inf depends on the underlying C library #10713
Comments
From @raflThis is a bug report for perl from rafl@debian.org, [Please describe your issue here] To stringify NVs containing NaN or Inf, the Gconvert macro is used. For most sprintf(buf, "%.*g", DBL_DIG, nv); That leaves the formatting of the NV up to the C library perl is working As it happens, different C libraries have different ways of formatting Not A So far Window's libc is the only one I've found to provide odd results for this, I think the Perl programmer shouldn't have to care about the details of the C Attached will be a patch adding tests for this. I've also pushed a branch |
From @rafl0001-Add-tests-for-stringifying-NaN-and-Inf.patchFrom 7e7b870751068e26e2d984893c5d24689c41ab01 Mon Sep 17 00:00:00 2001
From: Florian Ragwitz <rafl@debian.org>
Date: Mon, 11 Oct 2010 06:30:41 +0200
Subject: [PATCH] Add tests for stringifying NaN and Inf
---
t/base/num.t | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/t/base/num.t b/t/base/num.t
index fbeddc9..a2b084f 100644
--- a/t/base/num.t
+++ b/t/base/num.t
@@ -1,6 +1,6 @@
#!./perl
-print "1..53\n";
+print "1..57\n";
# First test whether the number stringification works okay.
# (Testing with == would exercize the IV/NV part, not the PV.)
@@ -209,3 +209,17 @@ print $a eq "16702650" ? "ok 52\n" : "not ok 52 # $a\n";
$a = 0B1101; "$a";
print $a eq "13" ? "ok 53\n" : "not ok 53 # $a\n";
+
+# NaN and Inf
+
+$a = 9 ** 9 ** 9; "$a";
+print $a eq "inf" ? "ok 54\n" : "not ok 54 # $a\n";
+
+$a = -9 ** 9 ** 9; "$a";
+print $a eq "-inf" ? "ok 55\n" : "not ok 55 # $a\n";
+
+$a = -sin 9 ** 9 ** 9; "$a";
+print $a eq "nan" ? "ok 56\n" : "not ok 56 # $a\n";
+
+$a = sin 9 ** 9 ** 9; "$a";
+print $a eq "-nan" ? "ok 57\n" : "not ok 57 # $a\n";
--
1.7.1
|
From @raflThis ticket is NOT about identical stringification of all NVs on all platforms Perl Info
|
From @doughera88On Mon, 11 Oct 2010, Florian Ragwitz wrote:
On the flip side, I think a user shouldn't have to worry about the details On balance, I'm actually not sure which way I lean on this one; I'd like -- |
The RT System itself - Status changed from 'new' to 'open' |
From @ikegamiOn Tue, Oct 12, 2010 at 11:21 AM, Andy Dougherty <doughera@lafayette.edu>wrote:
Does MinGW use MS's notation? There could very well be no such standard
Gimme code, and I'll run it through MS's compiler. - Eric Brine |
From ambrus@math.bme.huOn Tue, Oct 12, 2010 at 5:21 PM, Andy Dougherty <doughera@lafayette.edu> wrote:
The C99 standard describes the format infinity and nan should be Ambrus |
From @sisyphus----- Original Message -----
As regards the way that *perl* interprets the strings on Windows, it's a bit ########################## On my own MinGW-built perl 5.12.0 (and 5.12.2, too) , all seems well: ######################### The difference between the 3 perls is, of course, the compiler that built Even on perl 5.8.9 and 5.10.1 (but not 5.10.0, for some reason) MinGW32's I do have a couple of x64 builds of perl 5.12 (built using MinGW64's Cheers, |
From @cpansproutThis ticket is resolved, as perl now consistently uses NaN and Inf for stringification, as of 5.22. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#78330 (status was 'resolved')
Searchable as RT78330$
The text was updated successfully, but these errors were encountered: