Re: Year 2038 problem

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On 09/13/2011 06:29 PM, Eric Blake wrote:
> 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.
I second Sebastian's proposal - It's basically the same approach newlib 
applies for off_t/size_t, which allows RTEMS to use differently sized 
off_t/size_t's on different architectures.

This approach allows RTEMS to use 64bit types on architectures, where 
they "don't hurt" and 32bit types on architectures, where 64bit 
operations are "cheap".

> 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.
That's differently from what RTEMS does.

> But your overall idea of supporting 64-bit time_t on 32-bit platforms,
> via appropriate newlib patches, is indeed worth implementing.
Basically yes, except that 64bit ops are expensive on some architectures.

> 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.

Ralf