Year 2038 problem
Tue Sep 13 16:29:00 GMT 2011
On 09/12/2011 04:12 AM, Sebastian Huber wrote:
> 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:
> 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 email@example.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
More information about the Newlib