Introduction and 64 bit time_t
Wed Aug 9 11:32:00 GMT 2017
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
"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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Newlib