[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] new module: timegm

From: Paul Eggert
Subject: Re: [Bug-gnulib] new module: timegm
Date: 03 Sep 2003 14:08:18 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

I looked at the timegm.c implementation, and it has some bugs that
aren't easy to fix with the current approach.  For example, suppose I
have 32-bit time_t, I'm in New Zealand, and I invoke gnulib timegm on
the maximal UTC timestamp 2038-01-19 03:14:07.  This should work, but
timegm will invoke mktime which will fail because 2038-01-19 03:14:07
+1300 is not representable in 32-bits.  There are some other bugs like
that; also, I suspect also that the code is not robust in the presence
of leap seconds.

I've seen several attempts to implement timegm on top of mktime, and
they all have bugs like the one mentioned above; it's pretty much
inherent to that approach.

The simplest way to fix this problem is to switch to the glibc
implementation of timegm.  This is easy in gnulib, since the glibc
implementation merely invokes a mktime internal that is already in
timegm.  I take a look at doing this and will submit a proposed patch.

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
> > I used gmtime_r() where available(*),
> Yes, of course it's preferrable to use the MT-safe version of a function
> if possible.

Unfortunately many implementations of gmtime_r are buggy, and we don't
have a good test for them.  This problem is already noted in
lib/strftime.c.  Until we have a good test, we should punt and do as
lib/strftime.c does: namely, use gmtime and avoid gmtime_r.

> > Still, the code treat time_t as an arithmetic type, which I believe is
> > only permitted by POSIX, not C89.

That's OK.  C89 says that time_t is an arithmetic type; "(time_t) -1"
is in the C89 standard.

> > Another problem is if it should depend on the mktime module.  What is
> > the point of the mktime module, exactly?  The description says it
> > implement mktime, but the m4 file seem to check for various buggy
> > implementations.

Yes, there are a lot of them, including glibc-current.  On my list of
things to do is to backport gnulib mktime.c into glibc.

reply via email to

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