Re: Year 2038 problem

[Eric Blake <eblake at redhat dot com>]

On 09/13/2011 10:24 AM, Eric Blake wrote:
> On 09/12/2011 04:12 AM, Sebastian Huber wrote:
> > Hello,
> >
> > since time_t is usually defined as long in Newlib and thus 32-bit on
> > most 32-bit targets, we are affected by the year 2038 problem:
> >
> > http://en.wikipedia.org/wiki/Year_2038_problem
> >
> > Since have a system that should operate for 30 years we have to address
> > this problem somehow.
> >
> > What do you think about adding a configure option to define _TIME_T_ to
> > long long in "libc/include/machine/types.h" if requested?
>
> Making it a configure option is not a good idea. But we _do_ have plans
> to eventually make a backwards-compatible ABI change to cygwin1.dll that
> supports 64-bit time_t (similar to how cygwin 1.5 made a
> backwards-compatible ABI change to support 64-bit off_t compared to
> cygwin 1.3 with 32-bit off_t).

Actually, I spoke a bit prematurely, thinking in the context of just 
cygwin instead of all of newlib.

The real approach here is to do the same thing as we did for stdio 
between 32-bit and 64-bit.  Just as we have stdio/ for 32-bit operations 
and stdio64/ for 64-bit operations, where cygwin compiles both 
directories but then does magic to ensure that only the 64-bit version 
is exposed to new cygwin apps, we would need to do the same for every 
interface that uses time_t.

But your overall idea of supporting 64-bit time_t on 32-bit platforms, 
via appropriate newlib patches, is indeed worth implementing.  I just 
don't know if it needs a configure option, so much as it should copy 
what we did previously in newlib for the 64-bit off_t work.

--
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org