Bug #22392 for DateTime: t/20infinite.t fails (maybe due to 64 bit Perl)

Sat Oct 21 09:15:42 2006 FANY [...] cpan.org - Ticket created

Subject:

t/20infinite.t fails (maybe due to 64 bit Perl)

See output of "make test TEST_VERBOSE=1 TEST_FILES=t/20infinite.t" attached. Please note that I use a Perl interpreter with 64 bit integers and long doubles: ubook:/private/var/local/spool/perl/CPAN/build/DateTime-0.34 fany$ perl -VSummary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=darwin, osvers=8.5.0, archname=darwin-64int-ld-2level uname='darwin ubook.wlan 8.5.0 darwin kernel version 8.5.0: sun jan 22 10:38:46 pst 2006; root:xnu-792.6.61.obj~1release_ppc power macintosh powerpc ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement', optimize='-O3', cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement' ccversion='', gccversion='4.0.1 (Apple Computer, Inc. build 5250)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='' libpth=/usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup'Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_INT USE_LARGE_FILES USE_LONG_DOUBLE USE_PERLIO Built under darwin

Subject:

typescript

Download typescript
application/octet-stream 5.1k

Message body not shown because it is not plain text.

Sat Oct 21 13:54:16 2006 autarch [...] urth.org - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Sat, 21 Oct 2006 12:53:56 -0500 (CDT)
To:	via RT <bug-DateTime [...] rt.cpan.org>
From:	Dave Rolsky <autarch [...] urth.org>

On Sat, 21 Oct 2006, via RT wrote: Show quoted text

> Subject: t/20infinite.t fails (maybe due to 64 bit Perl)

That seems pretty likely. Unfortunately I don't have access to a 64-bit Perl myself. I'm signing up for Sourceforge's compile farm. Hopefully they'll have something I can use. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/

Sat Oct 21 13:54:18 2006 The RT System itself - Status changed from 'new' to 'open'

Sun Oct 22 01:27:26 2006 autarch [...] urth.org - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Sun, 22 Oct 2006 00:27:10 -0500 (CDT)
To:	"autarch [...] urth.org via RT" <bug-DateTime [...] rt.cpan.org>
From:	Dave Rolsky <autarch [...] urth.org>

On Sat, 21 Oct 2006, autarch@urth.org via RT wrote: Show quoted text

> That seems pretty likely. Unfortunately I don't have access to a 64-bit > Perl myself. I'm signing up for Sourceforge's compile farm. Hopefully > they'll have something I can use.

I tested this on the Sourceforge compile farm with a 64-bit Perl 5.8.5, and the tests passed. I think it's a platform issue. It seems like on non-Linux OSs, the handling of infinite numbers (at least in Perl) is different than what I see on Linux. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/

Thu Jan 18 11:22:07 2007 DROLSKY [...] cpan.org - Correspondence added

On Sat Oct 21 09:15:42 2006, FANY wrote: Show quoted text

> See output of "make test TEST_VERBOSE=1 TEST_FILES=t/20infinite.t"

attached. I just released a new version of DateTime.pm (0.36) that tweaks how infinity is defined. Could you try it out and see if this fixes the problem.

Sat Jan 20 11:12:02 2007 martin [...] sluka.de - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails
Date:	Sat, 20 Jan 2007 17:11:33 +0100
To:	via RT <bug-DateTime [...] rt.cpan.org>
From:	"Martin H. Sluka" <martin [...] sluka.de>

Hi, Show quoted text

> I just released a new version of DateTime.pm (0.36) that tweaks how > infinity is defined. Could you try it out and see if this fixes the problem.

thanks, but unfortunately I still get errors during this test on my iBook (please see output attached). Regards, fany -- _________________________________________ _ Martin H. Sluka \ tel +49-700-19751024 / ASCII ribbon ( ) Breite Straße 3 \ <martin@sluka.de> / campaign - against X D-90552 Röthenbach \ <http://unf.ug/> / HTML email & vcards / \

Download (untitled)
application/pgp-signature 307b

Message body not shown because it is not plain text.

Sat Jan 20 11:14:07 2007 martin [...] sluka.de - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails
Date:	Sat, 20 Jan 2007 17:13:48 +0100
To:	via RT <bug-DateTime [...] rt.cpan.org>
From:	"Martin H. Sluka" <martin [...] sluka.de>

Download (untitled)
application/pgp-signature 307b

Message body not shown because it is not plain text.

I've just written: Show quoted text

> thanks, but unfortunately I still get errors during this > test on my iBook (please see output attached).

Well.. Maybe I should attach it. :-) -- _________________________________________ _ Martin H. Sluka \ tel +49-700-19751024 / ASCII ribbon ( ) Breite Straße 3 \ <martin@sluka.de> / campaign - against X D-90552 Röthenbach \ <http://unf.ug/> / HTML email & vcards / \

Message body is not shown because sender requested not to inline it.

Thu Feb 22 19:49:53 2007 mschwern [...] cpan.org - Correspondence added

From:

MSCHWERN [...] cpan.org

Let me throw in a "me too!" I've got Perl compiled on a Redhat Linux ES3 machine (a 32 bit native system) with long doubles and 64 bit ints. Similar problem. Test and perl -V output attached.

Download test.out
application/octet-stream 117.6k

Message body not shown because it is not plain text.

Download perl_V
application/octet-stream 3k

Message body not shown because it is not plain text.

Thu Feb 22 19:51:56 2007 mschwern [...] cpan.org - Correspondence added

This may help: DB<2> x $pos 0 DateTime::Infinite::Future=HASH(0x85babf8) 'local_c' => HASH(0x88c4cf0) 'day' => '-2' 'day_of_quarter' => '-2' 'day_of_week' => '-2' 'day_of_year' => '-2' 'hour' => 86399 'minute' => 86399 'month' => '-2' 'quarter' => '-2' 'second' => 86399 'year' => '-2' 'local_rd_days' => '-2' 'local_rd_secs' => 86399 'rd_nanosecs' => '9.99999999999999999e+1999' 'tz' => DateTime::TimeZone::Floating=HASH(0x8825844) 'name' => 'floating' 'offset' => 0 'utc_rd_days' => '-2' 'utc_rd_secs' => 86399

Thu Feb 22 19:56:19 2007 mschwern [...] cpan.org - Correspondence added

Note that there is a real way to indicate Infinity and NaN in Perl. Its the strings "Infinity" and "NaN". I'm experimenting with using them rather than the Very Large Numbers currently used in DateTime.

Thu Feb 22 20:07:54 2007 mschwern [...] cpan.org - Correspondence added

Subject:

[PATCH] t/20infinite.t fails (maybe due to 64 bit Perl)

NEWBIE: How do you DO that? SIMON: It's simple. I have an infinite number of monkeys. Actually, it's only a MAXINT number of monkeys, but it's a good first-order approximation. The attached patch fixes the problem. Instead if 100 ** 1000 which is infinitely far away from being infinity, we use Perl's built in "inf" and "nan" values.

diff -ru DateTime-0.36/lib/DateTime.pm /home/schwern/.cpan/build/DateTime-0.36/lib/DateTime.pm --- DateTime-0.36/lib/DateTime.pm 2007-01-13 18:30:15.000000000 -0500 +++ /home/schwern/.cpan/build/DateTime-0.36/lib/DateTime.pm 2007-02-22 20:01:58.000000000 -0500 @@ -74,9 +74,10 @@ use constant MAX_NANOSECONDS => 1_000_000_000; # 1E9 = almost 32 bits -use constant INFINITY => 100 ** 1000; -use constant NEG_INFINITY => -1 * (100 ** 1000); -use constant NAN => INFINITY - INFINITY; +# We want the exact string used by Perl. +use constant INFINITY => 'Infinity' - 1; +use constant NEG_INFINITY => -1 * INFINITY; +use constant NAN => "NaN" - 1; use constant SECONDS_PER_DAY => 86400; Only in /home/schwern/.cpan/build/DateTime-0.36/lib: DateTime.pm~ Only in /home/schwern/.cpan/build/DateTime-0.36/: perl_V diff -ru DateTime-0.36/t/07compare.t /home/schwern/.cpan/build/DateTime-0.36/t/07compare.t --- DateTime-0.36/t/07compare.t 2007-01-13 18:29:30.000000000 -0500 +++ /home/schwern/.cpan/build/DateTime-0.36/t/07compare.t 2007-02-22 19:56:58.000000000 -0500 @@ -81,7 +81,7 @@ ok($date1->compare($date2) == 1, 'Comparison $a > $b, 1 year diff'); -my $infinity = 100 ** 1000; +my $infinity = DateTime::INFINITY; ok($date1->compare($infinity) == -1, 'Comparison $a < inf'); Only in /home/schwern/.cpan/build/DateTime-0.36/t: 07compare.t~ diff -ru DateTime-0.36/t/20infinite.t /home/schwern/.cpan/build/DateTime-0.36/t/20infinite.t --- DateTime-0.36/t/20infinite.t 2007-01-13 18:29:42.000000000 -0500 +++ /home/schwern/.cpan/build/DateTime-0.36/t/20infinite.t 2007-02-22 19:58:31.000000000 -0500 @@ -8,11 +8,11 @@ my $pos = DateTime::Infinite::Future->new; my $neg = DateTime::Infinite::Past->new; -my $posinf = 100 ** 1000; -my $neginf = -1 * $posinf; +my $posinf = DateTime::INFINITY; +my $neginf = DateTime::NEG_INFINITY; # used to use abs() which broke some Win32 platforms but may have # fixed others - will wait for bug reports -my $nan_string = ($posinf - $posinf) . ''; +my $nan_string = DateTime::NAN; # infinite date math { Only in /home/schwern/.cpan/build/DateTime-0.36/t: 20infinite.t~ Only in /home/schwern/.cpan/build/DateTime-0.36/: test.out

Fri Feb 23 04:18:34 2007 mschwern [...] cpan.org - Correspondence added

It turns out using the string "inf" as infinity was broken in some versions of Perl, 5.8.6 for example. This revised patch tries several ways to produce infinity. 1) 'inf' - 1 This is the safest, most direct way to get infinity and is tried first. -1 to reveal if 'inf' is really being treated as Infinity. If not it will be -1. 2) 2**2**31 A really big number will return 'inf' and 2 to the 2**31 is really big. But there's the risk of causing a floating point error and some systems which don't follow the IEEE conventions might not work. See t/op/arith.t in the perl core for the gory details. 3) Math::BigInt->binf If all else fails, use Math::BigInt. This is done last to avoid loading a module unnecessarily and because binf() was introduced in 2001 and might not be there in older Perls.

diff -ru DateTime-0.36/lib/DateTime.pm /home/schwern/.cpan/build/DateTime-0.36/lib/DateTime.pm --- DateTime-0.36/lib/DateTime.pm 2007-01-13 18:30:15.000000000 -0500 +++ /home/schwern/.cpan/build/DateTime-0.36/lib/DateTime.pm 2007-02-22 20:01:58.000000000 -0500 @@ -74,9 +74,10 @@ use constant MAX_NANOSECONDS => 1_000_000_000; # 1E9 = almost 32 bits -use constant INFINITY => 100 ** 1000; -use constant NEG_INFINITY => -1 * (100 ** 1000); -use constant NAN => INFINITY - INFINITY; +# We want the exact string used by Perl. +use constant INFINITY => 'Infinity' - 1; +use constant NEG_INFINITY => -1 * INFINITY; +use constant NAN => "NaN" - 1; use constant SECONDS_PER_DAY => 86400; Only in /home/schwern/.cpan/build/DateTime-0.36/lib: DateTime.pm~ Only in /home/schwern/.cpan/build/DateTime-0.36/: perl_V diff -ru DateTime-0.36/t/07compare.t /home/schwern/.cpan/build/DateTime-0.36/t/07compare.t --- DateTime-0.36/t/07compare.t 2007-01-13 18:29:30.000000000 -0500 +++ /home/schwern/.cpan/build/DateTime-0.36/t/07compare.t 2007-02-22 19:56:58.000000000 -0500 @@ -81,7 +81,7 @@ ok($date1->compare($date2) == 1, 'Comparison $a > $b, 1 year diff'); -my $infinity = 100 ** 1000; +my $infinity = DateTime::INFINITY; ok($date1->compare($infinity) == -1, 'Comparison $a < inf'); Only in /home/schwern/.cpan/build/DateTime-0.36/t: 07compare.t~ diff -ru DateTime-0.36/t/20infinite.t /home/schwern/.cpan/build/DateTime-0.36/t/20infinite.t --- DateTime-0.36/t/20infinite.t 2007-01-13 18:29:42.000000000 -0500 +++ /home/schwern/.cpan/build/DateTime-0.36/t/20infinite.t 2007-02-22 19:58:31.000000000 -0500 @@ -8,11 +8,11 @@ my $pos = DateTime::Infinite::Future->new; my $neg = DateTime::Infinite::Past->new; -my $posinf = 100 ** 1000; -my $neginf = -1 * $posinf; +my $posinf = DateTime::INFINITY; +my $neginf = DateTime::NEG_INFINITY; # used to use abs() which broke some Win32 platforms but may have # fixed others - will wait for bug reports -my $nan_string = ($posinf - $posinf) . ''; +my $nan_string = DateTime::NAN; # infinite date math { Only in /home/schwern/.cpan/build/DateTime-0.36/t: 20infinite.t~ Only in /home/schwern/.cpan/build/DateTime-0.36/: test.out

Sun Apr 15 03:23:03 2007 sthoenna [...] efn.org - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Sun, 15 Apr 2007 00:22:51 -0700 (PDT)
To:	bug-DateTime [...] rt.cpan.org
From:	"Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>

Just ran into this bug myself, trying to build with long doubles. I'd suggest just the attached patch, using the inf value successfully in use by B::Deparse. While it would be nice to support the systems that raise an FPE or don't actually support ieee-like infinite values, there's not an easy fix for that. FWIW, the weird values reported for $pos: 0 DateTime::Infinite::Future=HASH(0x85babf8) 'local_c' => HASH(0x88c4cf0) 'day' => '-2' 'day_of_quarter' => '-2' 'day_of_week' => '-2' 'day_of_year' => '-2' 'hour' => 86399 'minute' => 86399 'month' => '-2' 'quarter' => '-2' 'second' => 86399 'year' => '-2' 'local_rd_days' => '-2' 'local_rd_secs' => 86399 'rd_nanosecs' => '9.99999999999999999e+1999' 'tz' => DateTime::TimeZone::Floating=HASH(0x8825844) 'name' => 'floating' 'offset' => 0 'utc_rd_days' => '-2' 'utc_rd_secs' => 86399 are due to using 'use integer' or SvIV on UV values. This is quite possibly my fault: I used to think use integer was a neat idea, and used it in the old Date::ICal code. If the idea of using it came from there, I apologize for leading astray - use integer on arbitrary types of input values is a really bad idea.

Sun Apr 15 03:27:38 2007 sthoenna [...] efn.org - Correspondence added

CC:	bug-datetime [...] rt.cpan.org
Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Sun, 15 Apr 2007 00:26:59 -0700 (PDT)
To:	"Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>
From:	"Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>

On Sun, April 15, 2007 12:22 am, Yitzchak Scott-Thoennes wrote: Show quoted text

> I'd suggest just the attached patch, using the inf value successfully > in use by B::Deparse.

Now with 100% more attachments!

Message body is not shown because sender requested not to inline it.

Sun Apr 15 08:53:31 2007 autarch [...] urth.org - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Sun, 15 Apr 2007 07:53:01 -0500 (CDT)
To:	Yitzchak Scott-Thoennes via RT <bug-DateTime [...] rt.cpan.org>
From:	Dave Rolsky <autarch [...] urth.org>

On Sun, 15 Apr 2007, Yitzchak Scott-Thoennes via RT wrote: Show quoted text

> are due to using 'use integer' or SvIV on UV values. This is quite > possibly my fault: I used to think use integer was a neat idea, and > used it in the old Date::ICal code. If the idea of using it came > from there, I apologize for leading astray - use integer on arbitrary > types of input values is a really bad idea.

So are you suggesting I remove all use of "use integer" from the DateTime.pm code? -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/

Thu Apr 19 04:18:21 2007 sthoenna [...] efn.org - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Thu, 19 Apr 2007 01:18:03 -0700 (PDT)
To:	"Dave Rolsky" <autarch [...] urth.org>, bug-DateTime [...] rt.cpan.org
From:	"Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>

On Sun, 15 Apr 2007, Dave Rolsky wrote: Show quoted text

> So are you suggesting I remove all use of "use integer" from the > DateTime.pm code?

Or validate that your inputs are within the range of an IV. If not, you'd need to add some int()s, and think about floating point lack of precision. And in XS, you'd need to avoid SvIVs. For instance, both versions of _normalize_tai_seconds are broken in the same way for finite numbers greater than IV_MAX ( ~0 >> 1 in non-use-integer pure perl ), though the XS version obviously doesn't have a "use integer" in it.

Sun Apr 22 21:51:01 2007 sthoenna [...] efn.org - Correspondence added

Subject:	Re: [rt.cpan.org #22392] t/20infinite.t fails (maybe due to 64 bit Perl)
Date:	Sun, 22 Apr 2007 18:50:45 -0700 (PDT)
To:	"Dave Rolsky" <autarch [...] urth.org>, bug-datetime [...] rt.cpan.org
From:	"Yitzchak Scott-Thoennes" <sthoenna [...] efn.org>

On Thu, April 19, 2007 1:18 am, Yitzchak Scott-Thoennes wrote: Show quoted text

> On Sun, 15 Apr 2007, Dave Rolsky wrote: >

>> So are you suggesting I remove all use of "use integer" from the >> DateTime.pm code? >>

> > Or validate that your inputs are within the range of an IV. > If not, you'd need to add some int()s, and think about floating > point lack of precision. > > And in XS, you'd need to avoid SvIVs. For instance, both versions of > _normalize_tai_seconds are broken in the same way for finite numbers > greater than IV_MAX ( ~0 >> 1 in non-use-integer pure perl ), though the XS > version obviously doesn't have a "use integer" in it.

If it wasn't clear, this is all a side issue that only relates to this bug ticket in that the existing expression for INFINITY is finite under long doubles, and when perl attempts to get an integer value for it, it gives UV_MAX, which, when cast to an IV via "use integer" or an SvIV that ignores SvIsUV, is -1. The fix for *this* bug #22392 is just to use a better expression for infinitity, as the suggested patch does.

Mon Jul 16 21:13:03 2007 dagolden [...] cpan.org - Correspondence added

From:

DAGOLDEN [...] cpan.org

On Sun Apr 22 21:51:01 2007, sthoenna@efn.org wrote: Show quoted text

> The fix for *this* bug #22392 is just to use a better expression for > infinitity, as the suggested patch does.

I can confirm that Yitzchak's patch fixes this bug for 0.38 on Perl 5.8.8 i686-linux-64int-ld (a Core 2 Duo), whereas the unpatched 0.38 fails t/20inifinite.t. Dave -- could we please get a 0.39 release soon with this patch? DateTime has become a fairly common dependency, I believe. Thank you very much. Regards, David

Sun Jul 26 23:40:54 2009 YSTH [...] cpan.org - Correspondence added

On Sun Apr 15 03:27:38 2007, sthoenna@efn.org wrote: Show quoted text

> On Sun, April 15, 2007 12:22 am, Yitzchak Scott-Thoennes wrote:

> > I'd suggest just the attached patch, using the inf value successfully > > in use by B::Deparse.

> > Now with 100% more attachments!

This patch was put in some time ago; this bug should be closed.

Mon Jul 27 00:22:09 2009 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jul 27 00:22:09 2009 DROLSKY [...] cpan.org - Fixed in 0.39 added

Bug #22392 for DateTime: t/20infinite.t fails (maybe due to 64 bit Perl)

Preferred bug tracker