Re: Introduction and 64 bit time_t

[Corinna Vinschen <vinschen at redhat dot com>]

On Aug  8 10:55, Joel Sherrill wrote:
> On 8/8/2017 10:39 AM, Eric Blake wrote:
> > On 08/08/2017 07:40 AM, Philipp.Trommler@preh.de wrote:
> > > My impression is that you're in principle interested in having a fix
> > > for the problem but you didn't have the resources to do it until now.
> > > If this impression is right, I'd gladly provide a fix but I'll need
> > > some advice from developers more experienced in newlib.
> > > 
> > > So here are my questions:
> > > 
> > > 1. Are you interested in a fix for the problem? If yes, what are the
> > >     steps that are necessary from your point of view? What are your
> > >     preferences for a possible implementation?
> > 
> > Yes, we're interested. It sounds like any solution will have to be gated
> > by compile-time conditionals around the typedef for time_t (so that
> > embedded platforms don't have to pay the size penalties when they don't
> > care about the larger range of time).

Interesting.  I would have answered the question with "No, we don't have
that problem.  Much."

The newlib functions handling time_t are working fine with 32 and 64 bit
time_t, so there's nothing to do to get 64 bit time_t functionality.
Keep in mind that Cygwin is using 64 bit time_t on x86_64 for quite some
time now.

"Much", because the way time_t is defined is jusst a tad a bit unlucky:

- time_t is generally typedef'ed to _TIME_T_, so that's good.

- But _TIME_T_ is indiscriminately defined as long in sys/_types.h

Only the latter aspect needs rethinking.  In case of 32 bit Cygwin we
also need to stick to a 4 byte type, unless "somebody(TM)" takes an
interest and the time to change the Cygwin DLL to 64 bit time_t for 32
bit applications as well.  Lots and lots of wrapping is required to keep
older executables running.

> I can't find the email in the rtems.org mailing lists but performance
> is also an issue. I recall at least two CPUs where 64 bit math performance
> was bad.

I wouldn't overvalue that if only a few CPUs are affected.  There's
always a chance to improve the required math functions for those if
the level of suffering gets too high.

> That said, I think moving to 64-bit time_t is inevitable and
> mostly overdue. I know RTEMS users have posted about fielding
> systems with lifespans expected past 2038.

ACK


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature