[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: removed uninit-64 test
From: |
Jim Meyering |
Subject: |
Re: removed uninit-64 test |
Date: |
Sat, 24 Sep 2005 10:05:31 +0200 |
Paul Eggert <address@hidden> wrote:
> CVS coreutils "make check" failed on 64-bit Solaris 8, because its
> localtime function returns garbage in tm_year when time_t has an
> outlandishly large year. It is a bug, but it's not a coreutils bug.
> Also, the test wouldn't work on a bug-free host with a 64-bit int.
> Maybe there's a way to resurrect the test so that it doesn't have
> these false reports, but I couldn't think of it.
>
> 2005-09-24 Paul Eggert <address@hidden>
>
> * tests/misc/date (uninit-64): Remove this test. It wasn't
> portable in theory (it doesn't work on hosts where 'int' is 64
> bits, example) or in practice (Solaris 8 localtime returns garbage
> in tm_year for the specified date, but that's not coreutils's
> fault).
Thanks for looking into that.
It was also a problem on an alphaev56-dec-osf4.0f system.
However, I didn't like the idea of dropping the test everywhere just
because it gets spurious failures due to a couple of buggy localtime
implementations, so I did this:
2005-09-24 Jim Meyering <address@hidden>
* tests/misc/date (uninit-64): Restore this test.
Add start-up code to detect, and work around, the cases in
which the test might fail.
Can you confirm that it works on your Solaris 8 system?
Index: date
===================================================================
RCS file: /fetish/cu/tests/misc/date,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -u -r1.20 -r1.21
--- date 24 Sep 2005 07:05:27 -0000 1.20
+++ date 24 Sep 2005 07:57:36 -0000 1.21
@@ -36,6 +36,20 @@ my $dy = '1998-01-19'; # next month
my $fmt = "'+%Y-%m-%d %T'";
+# Determine a number of seconds that will provoke an invalid
+# time diagnostic from date. If possible, use a number that
+# is less than 2^64, yet so large that it would cause the resulting
+# tm_year value to be too large for a 32-bit int. But some systems
+# (Solaris 8) have a buggy localtime that mistakenly accepts such
+# invalid times and give garbage in tm_year. Other systems might
+# have an int type that is wider than 32. So if this localtime
+# call succeeds, use 2^64 as the number of seconds.
+my $n_seconds = 72057594037927935;
+my @d = localtime ($n_seconds);
+my $year = $d[5];
+defined $year
+ and $n_seconds = '18446744073709551616';
+
my @Tests =
(
# test-name, [option, option, ...] {OUT=>"expected-output"}
@@ -223,6 +237,23 @@ my @Tests =
['neg-secs', '-d @-22 +%05s', {OUT=>"-0022"}],
['neg-secs2', '-d @-22 +%_5s', {OUT=>" -22"}],
+ # Before today's fix, date would print uninitialized data
+ # to standard output for an out-of-range date:
+ # $ date -d @$(echo 2^56-1|bc) 2> /dev/null | od -a -N3
+ # 0000000 p 4 6
+ # 0000003
+ ['uninit-64', "-d address@hidden",
+ {OUT=>''},
+ # Use ERR_SUBST to get around fact that the diagnostic
+ # you get on a system with 32-bit time_t is not the same as
+ # the one you get for a system where it's 64 bits wide:
+ # - date: time 72057594037927935 is out of range
+ # + date: invalid date address@hidden'
+ {ERR_SUBST => 's/.*//'},
+ {ERR => "\n"},
+ {EXIT => 1},
+ ],
+
['fill-1', '-d 1999-12-08 +%_3d', {OUT=>' 8'}],
['fill-2', '-d 1999-12-08 +%03d', {OUT=>'008'}],