Re: removed uninit-64 test

[Jim Meyering]

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'}],