[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] Re: GNULIB mktime.c compilation failure on UNICOS 9.0 C
Mark D. Baushke
Re: [Bug-gnulib] Re: GNULIB mktime.c compilation failure on UNICOS 9.0 Cray Y-MP EL
Wed, 10 Nov 2004 16:49:21 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Paul Eggert <address@hidden> writes:
> "Mark D. Baushke" <address@hidden> writes:
> > The getdate test program has one problem....
> > I am guessing this is because all integral numbers on UNICOS are 8
> > bytes.
> That test case has three bugs. First, the comment
> # Feb. 29, 2096 8 years
> # 8 years from this date is _not_ a leap year, so Feb. 29th does not exist.
> is incorrect, since 2104 is a leap year.
> Second, on this example getdate fails on 32-bit hosts because 2104
> isn't representable, but as you noted it will succeed on 64-bit hosts,
> so the test case isn't portable.
Even worse, most hosts have a maximum of 31-bit postive values for
time_t which means that any date past 'Jan 19 2038 03:14:07 +0000'
would be the maximum...
> Third, the underlying motivation for the test case is incorrect. For
> date arithmetic getdate defers to mktime, so examples like "Feb. 29,
> 2004 +1 year" succeed, and return values like 2005-03-01. I suppose
> that one could argue that this is the "wrong" answer, but one can just
> as easily argue that it's a correct answer, and that it's better to
> return an answer rather than fail. Here's another argument: the
> string "now +1 year" should always succeed, but if the current date is
> Feb. 29 it would fail if getdate took the persnickety interpretation.
> The simplest fix is to remove that particular test case.
Agreed. I have done so.
> > Please commit your change to GNULIB.
> I've submitted a bug report to glibc here:
> When the fix is committed it should propagate to gnulib.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----