This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/1] Y2038: add function __difftime64
- From: Zack Weinberg <zackw at panix dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>, Gnulib bugs <bug-gnulib at gnu dot org>
- Date: Thu, 5 Jul 2018 15:13:10 -0400
- Subject: Re: [PATCH 1/1] Y2038: add function __difftime64
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20180620225545.4eb76291@athena> <email@example.com> <20180626003245.023eb716@athena> <firstname.lastname@example.org> <20180627130342.41cc6992@athena> <20180705203637.66ae4947@athena>
On Thu, Jul 5, 2018 at 2:36 PM, Albert ARIBAUD <email@example.com> wrote:
> I have had a look at gnulib in the meantime, and I would like to know
> if the following assumptions are correct:
I can't comment on anything else at all, but:
> - gnulib does not contain any module which provides the time_t type, but
> some of gnulib's modules assume there is such a type, and it might be
> wider than 32 bits.
> - gnulib does not provide difftime either, so ATM a difftime patch
> would only make sense in glibc, not gnulib.
<time.h> has always been required to declare a type named time_t and a
function named difftime, ever since the original C standard in 1989.
So it makes sense for gnulib not to provide either, and to assume they
In the original C standard time_t is only required to be "an
arithmetic type capable of representing times". That means it could
be any size of integer or floating-point. This has not changed as of
C11 -- the term "arithmetic type" changed to "real type" because of
the addition of complex numbers, but that's all. POSIX adds the
additional guarantee that time_t is an integer type, but still says
nothing about how wide it is.