[Top][All Lists]

[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

From: Mark D. Baushke
Subject: Re: [Bug-gnulib] Re: GNULIB mktime.c compilation failure on UNICOS 9.0 Cray Y-MP EL
Date: Wed, 10 Nov 2004 16:49:21 -0800

Hash: SHA1

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:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=541
> When the fix is committed it should propagate to gnulib.

Thank you.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]