Year 2038 problem

[Eric Blake]

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).  It is done by making the dll provide two 
entry points (32-bit and 64-bit versions), where new apps will 
automatically be compiled to use the 64-bit entry, and older apps 
compiled with the 32-bit entry will continue to work insofar as they 
don't overflow.  But getting to that point will affect a lot of cygwin 
internal code, and requires someone to actually write the patch(es).

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