This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Introduction and 64 bit time_t
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Eric Blake <eblake at redhat dot com>, "Philipp dot Trommler at preh dot de" <Philipp dot Trommler at preh dot de>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 8 Aug 2017 10:55:36 -0500
- Subject: Re: Introduction and 64 bit time_t
- Authentication-results: sourceware.org; auth=none
- References: <1502196045.32750.41.camel@preh.de> <af15d4a6-cc3b-0acf-feb2-e3383e2efb6d@redhat.com>
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).
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.
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.
2. Sadly I'm unable to check out your latest code locally, as cloning
the git repository via HTTP (the git protocol is no option in our
company's network, sorry) fails with some "Unable to get pack
index..." and "Unable to get pack file..." errors. Is this just me
or is something wrong with your git server?
If you need HTTP clones, it's easy to use a third-party tracking repo; I
find that repo.or.cz makes it very easy to set up a tracking clone
(generally lags the official repo by less than an hour), and then get
your HTTP from there rather than upstream ('git config
url.$name.insteadof' can make it even easier to automatically rewrite
your local accesses to redirect to your preferred http alternative).
--joel
RTEMS