Introduction and 64 bit time_t

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Introduction and 64 bit time_t

Philipp.Trommler@preh.de
Hi!

First of all, I'd like to introduce myself: My name is Philipp
Trommler, I'm from Germany and my employer is Preh Car Connect GmbH.
Part of my job is working with newlib, especially when it comes to time
and clocks, which is why I'm writing this mail.

In our products we need to provide support for quite a long time, thus
the year 2038 problem is relevant for us right now. And from what I can
see in your online git frontend, newlib is still affected by this
problem.

I've searched your mailing list archive and stumbled upon two threads
that mention the problem. The first one [1] is quite up-to-date but
received no responses, the second one [2] got some productive feedback
but is nearly 8 years old. 

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?

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?

Regards
Philipp


[1] https://sourceware.org/ml/newlib/2016/msg01061.html
[2] https://sourceware.org/ml/newlib/2009/msg00911.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Eric Blake-3
On 08/08/2017 07:40 AM, [hidden email] 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).

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

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


signature.asc (632 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Joel Sherrill <joel@OARcorp.com>


On 8/8/2017 10:39 AM, Eric Blake wrote:

> On 08/08/2017 07:40 AM, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
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, [hidden email] 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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Philipp.Trommler@preh.de
Am Mittwoch, den 09.08.2017, 13:32 +0200 schrieb Corinna Vinschen:

[snip]

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

So you're saying that defining _TIME_T_ as long long instead of long
(guarded by conditionals respecting those "old" Cygwin applications and
users who don't want to use a 64 bit time_t) would be enough?

>
> >
> > 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
On Aug  9 12:17, [hidden email] wrote:

> Am Mittwoch, den 09.08.2017, 13:32 +0200 schrieb Corinna Vinschen:
>
> [snip]
>
> > 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.
>
> So you're saying that defining _TIME_T_ as long long instead of long
> (guarded by conditionals respecting those "old" Cygwin applications and
> users who don't want to use a 64 bit time_t) would be enough?
I'd prefer to use the type long on LP64 systems, but long long should
work fine for all 32 bit systems (baring 32 bit Cygwin).

However, a developer might want to design an embedded system still using
a 32 bit time_t for the time being, so there should be some build-time
switch for this case.  We're talking about a 21 year timeframe, which
may still be more than enough for some systems.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Freddie Chopin
In reply to this post by Philipp.Trommler@preh.de
Hi!

If it is of any worth, personally I would prefer an "--enable-
something" configure switch for that, so that it would be easy to
compile newlib with selected configuration without need to modify any
sources.

Regards,
FCh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Philipp.Trommler@preh.de
In reply to this post by Corinna Vinschen
Am Mittwoch, den 09.08.2017, 14:35 +0200 schrieb Corinna Vinschen:

[snip]

> I'd prefer to use the type long on LP64 systems, but long long should
> work fine for all 32 bit systems (baring 32 bit Cygwin).
>
> However, a developer might want to design an embedded system still
> using
> a 32 bit time_t for the time being, so there should be some build-
> time
> switch for this case.  We're talking about a 21 year timeframe, which
> may still be more than enough for some systems.

So we can agree on a build-time switch like --enable-long-long-time-t
which defaults to off? That way the compilation of newlib itself could
be handled easily, but for the compilation of applications using time_t
I'm facing (at least) two possible implementations:

1. Having the user define something before including time.h in order to
   select the non-default long long, e.g.

      #define _USE_LONG_LONG_TIME_T
      #include <time.h>

2. Rewriting either time.h or sys/types.h at build-time depending on
   the configure switch to define this value or, even simpler, rewrite
   the definition of _TIME_T_ at build-time.

Am I correct here and which of these implementations would you prefer?
Or am I missing something completely here?

Regards
Philipp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
On Aug  9 13:47, [hidden email] wrote:

> Am Mittwoch, den 09.08.2017, 14:35 +0200 schrieb Corinna Vinschen:
>
> [snip]
>
> > I'd prefer to use the type long on LP64 systems, but long long should
> > work fine for all 32 bit systems (baring 32 bit Cygwin).
> >
> > However, a developer might want to design an embedded system still
> > using
> > a 32 bit time_t for the time being, so there should be some build-
> > time
> > switch for this case.  We're talking about a 21 year timeframe, which
> > may still be more than enough for some systems.
>
> So we can agree on a build-time switch like --enable-long-long-time-t
> which defaults to off? That way the compilation of newlib itself could
> be handled easily, but for the compilation of applications using time_t
> I'm facing (at least) two possible implementations:
>
> 1. Having the user define something before including time.h in order to
>    select the non-default long long, e.g.
>
>       #define _USE_LONG_LONG_TIME_T
>       #include <time.h>
>
> 2. Rewriting either time.h or sys/types.h at build-time depending on
>    the configure switch to define this value or, even simpler, rewrite
>    the definition of _TIME_T_ at build-time.
>
> Am I correct here and which of these implementations would you prefer?
> Or am I missing something completely here?
newlib/newlib.hin


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
In reply to this post by Freddie Chopin
On Aug  9 15:01, Freddie Chopin wrote:
> Hi!
>
> If it is of any worth, personally I would prefer an "--enable-
> something" configure switch for that, so that it would be easy to
> compile newlib with selected configuration without need to modify any
> sources.

Enable what exactly?

In theory, it's time to move to 64 bit time_t by default, so some
--enable-32bit-time_t should be the right thing to do, shouldn't it?


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
In reply to this post by Philipp.Trommler@preh.de
On Aug  9 13:47, [hidden email] wrote:

> Am Mittwoch, den 09.08.2017, 14:35 +0200 schrieb Corinna Vinschen:
>
> [snip]
>
> > I'd prefer to use the type long on LP64 systems, but long long should
> > work fine for all 32 bit systems (baring 32 bit Cygwin).
> >
> > However, a developer might want to design an embedded system still
> > using
> > a 32 bit time_t for the time being, so there should be some build-
> > time
> > switch for this case.  We're talking about a 21 year timeframe, which
> > may still be more than enough for some systems.
>
> So we can agree on a build-time switch like --enable-long-long-time-t
What about --enable-32bit-time_t or something like that?  By default
time_t should default to long on targets with sizeof(long)==8 and to
long long on targets with sizeof(long)==4.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Hans-Bernhard Bröker
Am 09.08.2017 um 17:51 schrieb Corinna Vinschen:

> What about --enable-32bit-time_t or something like that?  By default
> time_t should default to long on targets with sizeof(long)==8 and to
> long long on targets with sizeof(long)==4.

Wouldn't it appear more elegant to just say:

        By default time_t should default to uint64_t.

or, if we want to be _really_ picky,

        By default time_t should default to uint_least64_t.

Or do we pretend C99 didn't happen?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Freddie Chopin
In reply to this post by Corinna Vinschen
On Wed, 2017-08-09 at 17:47 +0200, Corinna Vinschen wrote:

> On Aug  9 15:01, Freddie Chopin wrote:
> > Hi!
> >
> > If it is of any worth, personally I would prefer an "--enable-
> > something" configure switch for that, so that it would be easy to
> > compile newlib with selected configuration without need to modify
> > any
> > sources.
>
> Enable what exactly?
>
> In theory, it's time to move to 64 bit time_t by default, so some
> --enable-32bit-time_t should be the right thing to do, shouldn't it?

I don't have any preference here, as long as there exists a configure
switch to select between 32-bit and 64-bit time_t, whichever will be
default (;

Regards,
FCh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Joel Sherrill <joel@OARcorp.com>


On 8/9/2017 1:43 PM, Freddie Chopin wrote:

> On Wed, 2017-08-09 at 17:47 +0200, Corinna Vinschen wrote:
>> On Aug  9 15:01, Freddie Chopin wrote:
>>> Hi!
>>>
>>> If it is of any worth, personally I would prefer an "--enable-
>>> something" configure switch for that, so that it would be easy to
>>> compile newlib with selected configuration without need to modify
>>> any
>>> sources.
>>
>> Enable what exactly?
>>
>> In theory, it's time to move to 64 bit time_t by default, so some
>> --enable-32bit-time_t should be the right thing to do, shouldn't it?
>
> I don't have any preference here, as long as there exists a configure
> switch to select between 32-bit and 64-bit time_t, whichever will be
> default (;

And a way for targets to set their own default like some of the
other internal settings? (Just a question)
 
> Regards,
> FCh
>

--joel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
In reply to this post by Hans-Bernhard Bröker
On Aug  9 18:59, Hans-Bernhard Bröker wrote:

> Am 09.08.2017 um 17:51 schrieb Corinna Vinschen:
>
> > What about --enable-32bit-time_t or something like that?  By default
> > time_t should default to long on targets with sizeof(long)==8 and to
> > long long on targets with sizeof(long)==4.
>
> Wouldn't it appear more elegant to just say:
>
> By default time_t should default to uint64_t.
>
> or, if we want to be _really_ picky,
>
> By default time_t should default to uint_least64_t.
>
> Or do we pretend C99 didn't happen?
s/uint64_t/int64_t/
s/int64_t/__int64_t/

Otherwise, sure.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Corinna Vinschen
In reply to this post by Joel Sherrill <joel@OARcorp.com>
On Aug  9 13:53, Joel Sherrill wrote:

>
>
> On 8/9/2017 1:43 PM, Freddie Chopin wrote:
> > On Wed, 2017-08-09 at 17:47 +0200, Corinna Vinschen wrote:
> > > On Aug  9 15:01, Freddie Chopin wrote:
> > > > Hi!
> > > >
> > > > If it is of any worth, personally I would prefer an "--enable-
> > > > something" configure switch for that, so that it would be easy to
> > > > compile newlib with selected configuration without need to modify
> > > > any
> > > > sources.
> > >
> > > Enable what exactly?
> > >
> > > In theory, it's time to move to 64 bit time_t by default, so some
> > > --enable-32bit-time_t should be the right thing to do, shouldn't it?
> >
> > I don't have any preference here, as long as there exists a configure
> > switch to select between 32-bit and 64-bit time_t, whichever will be
> > default (;
>
> And a way for targets to set their own default like some of the
> other internal settings? (Just a question)
sys/config.h, as usual?


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Sebastian Huber-4
In reply to this post by Philipp.Trommler@preh.de
Hello Philipp,

here is an example for how to add a new configure option:

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=a254c82486fd405623f1655383ee67e96216a883;hp=d2e256a36a877fca17272c2e4640d967ea8c490f


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Introduction and 64 bit time_t

Philipp.Trommler@preh.de
In reply to this post by Corinna Vinschen
Hi again,

first of all, thanks to Sebastion for his example of how to add
something like that to newlib. It really helped me getting my feet wet.

In the reply to this mail is the patch I came up with in order to
define time_t to an appropriate type. I'm happy for any feedback on it.

However, during the tests I did, I recognized that though sizeof(time_t)
has been 8 now, our software did a wrap-around in January 2038. I was
able to track it down to gmtime_r where the time_t lcltime gets casted
to long in order to fit into days and rem.

Having days and rem be a time_t and removing the casts fixes the wrap-
around for me, but I highly suspect that this is not a *clean* way to do
it. What are your sugestions on this? Which type should days and rem
have?

Regards
Philipp


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] Changes the default size of time_t to 64 bit.

Philipp.Trommler@preh.de
From: Philipp Trommler <[hidden email]>

This fixes the year 2038 problem by defining _TIME_T_ to either
__int_least64_t, __int64_t, long (on 64 bit machines) or long long,
depending on the available types.

Additionally, a new configure switch --enable-32bit-time_t has been
added to force _TIME_T_ to long, architecture independent, in order to
be backward compatible and allow users to use the smaller timestamp
when needed.

Signed-off-by: Philipp Trommler <[hidden email]>
---
 newlib/README                    |  7 +++++++
 newlib/configure                 | 27 +++++++++++++++++++++++++--
 newlib/configure.in              | 15 +++++++++++++++
 newlib/libc/include/sys/_types.h | 15 +++++++++++++++
 newlib/libc/include/sys/config.h |  7 +++++++
 newlib/newlib.hin                |  3 +++
 6 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/newlib/README b/newlib/README
index 78f4de8..d1dface 100644
--- a/newlib/README
+++ b/newlib/README
@@ -343,6 +343,13 @@ One feature can be enabled by specifying `--enable-FEATURE=yes' or
      disables the optimization and saves size of text and stack.
      Enabled by default.
 
+`--enable-32bit-time_t'
+     Use a time_t that is defined to long, regardless of the wordsize of
+     the target. This may lead to problems in January 2038 when the 32 bit
+     timestamp overflows but on the other hand may yield better
+     performance than 64 bit timestamps.
+     Disabled by default.
+
 `--enable-multilib'
      Build many library versions.
      Enabled by default.
diff --git a/newlib/configure b/newlib/configure
index b2f0b33..fa49706 100755
--- a/newlib/configure
+++ b/newlib/configure
@@ -804,6 +804,7 @@ enable_newlib_unbuf_stream_opt
 enable_lite_exit
 enable_newlib_nano_formatted_io
 enable_newlib_retargetable_locking
+enable_32bit_time_t
 enable_multilib
 enable_target_optspace
 enable_malloc_debugging
@@ -1477,6 +1478,9 @@ Optional Features:
   --enable-lite-exit enable light weight exit
   --enable-newlib-nano-formatted-io    Use nano version formatted IO
   --enable-newlib-retargetable-locking    Allow locking routines to be retargeted at link time
+  --enable-32bit-time_t   enable the 32 bit time_t which is affected by the
+                          year 2038 problem but may result in better
+                          performance
   --enable-multilib         build many library versions (default)
   --enable-target-optspace  optimize for space
   --enable-malloc-debugging indicate malloc debugging requested
@@ -2501,6 +2505,18 @@ else
 fi
 
 
+# Check whether --enable-32bit-time_t was given.
+if test "${enable_32bit_time_t+set}" = set; then :
+  enableval=$enable_32bit_time_t; case "${enableval}" in
+   yes) newlib_want_long_time_t=yes ;;
+   no)  newlib_want_long_time_t=no  ;;
+   *) as_fn_error $? "bad value ${enableval} for newlib_want_long_time_t option" "$LINENO" 5 ;;
+ esac
+else
+  newlib_want_long_time_t=no
+fi
+
+
 
 # Make sure we can run config.sub.
 $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
@@ -11807,7 +11823,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11810 "configure"
+#line 11826 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11913,7 +11929,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11916 "configure"
+#line 11932 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12496,6 +12512,13 @@ _ACEOF
 
 fi
 
+if test "${newlib_want_long_time_t}" = "yes"; then
+cat >>confdefs.h <<_ACEOF
+#define _WANT_LONG_TIME_T 1
+_ACEOF
+
+fi
+
 
 if test "x${iconv_encodings}" != "x" \
    || test "x${iconv_to_encodings}" != "x" \
diff --git a/newlib/configure.in b/newlib/configure.in
index 5b86ee8..4d5f7d0 100644
--- a/newlib/configure.in
+++ b/newlib/configure.in
@@ -238,6 +238,17 @@ AC_ARG_ENABLE(newlib-retargetable-locking,
    *) AC_MSG_ERROR(bad value ${enableval} for newlib-retargetable-locking) ;;
  esac],[newlib_retargetable_locking=no])
 
+dnl Support --enable-32bit-time_t
+AC_ARG_ENABLE(32bit-time_t,
+[AS_HELP_STRING([--enable-32bit-time_t],
+                [enable the 32 bit time_t which is affected by the year
+                 2038 problem but may result in better performance])],
+[case "${enableval}" in
+   yes) newlib_want_long_time_t=yes ;;
+   no)  newlib_want_long_time_t=no  ;;
+   *) AC_MSG_ERROR(bad value ${enableval} for newlib_want_long_time_t option) ;;
+ esac],[newlib_want_long_time_t=no])
+
 NEWLIB_CONFIGURE(.)
 
 dnl We have to enable libtool after NEWLIB_CONFIGURE because if we try and
@@ -486,6 +497,10 @@ if test "${newlib_retargetable_locking}" = "yes"; then
 AC_DEFINE_UNQUOTED(_RETARGETABLE_LOCKING)
 fi
 
+if test "${newlib_want_long_time_t}" = "yes"; then
+AC_DEFINE_UNQUOTED(_WANT_LONG_TIME_T)
+fi
+
 dnl
 dnl Parse --enable-newlib-iconv-encodings option argument
 dnl
diff --git a/newlib/libc/include/sys/_types.h b/newlib/libc/include/sys/_types.h
index 98b93ce..09be6b0 100644
--- a/newlib/libc/include/sys/_types.h
+++ b/newlib/libc/include/sys/_types.h
@@ -183,7 +183,22 @@ typedef void *_iconv_t;
 #define _CLOCK_T_ unsigned long /* clock() */
 typedef _CLOCK_T_ __clock_t;
 
+#if defined(_USE_LONG_TIME_T)
+/* User decided to use short time_t */
 #define _TIME_T_ long /* time() */
+#else
+#if defined(___int_least64_t_defined)
+#define _TIME_T_ __int_least64_t
+#elif defined(___int64_t_defined)
+#define _TIME_T_ __int64_t
+#else
+#if __LONG_MAX__ >= 9223372036854775807L
+#define _TIME_T_ long
+#else
+#define _TIME_T_ long long
+#endif /* __LONG_MAX__ >= 9223372036854775807L */
+#endif /* ___int_least64_t_defined / ___int64_t_defined / neither */
+#endif /* defined(_USE_LONG_TIME_T) */
 typedef _TIME_T_ __time_t;
 
 #define _CLOCKID_T_ unsigned long
diff --git a/newlib/libc/include/sys/config.h b/newlib/libc/include/sys/config.h
index 117c49a..f069630 100644
--- a/newlib/libc/include/sys/config.h
+++ b/newlib/libc/include/sys/config.h
@@ -283,6 +283,13 @@
 #endif
 #endif
 
+/* If _USE_LONG_TIME_T is set, a long is used for time_t */
+#ifdef _WANT_LONG_TIME_T
+#ifndef _USE_LONG_TIME_T
+#define _USE_LONG_TIME_T
+#endif
+#endif
+
 /* If _MB_EXTENDED_CHARSETS_ALL is set, we want all of the extended
    charsets.  The extended charsets add a few functions and a couple
    of tables of a few K each. */
diff --git a/newlib/newlib.hin b/newlib/newlib.hin
index 45c6831..a8b6bf6 100644
--- a/newlib/newlib.hin
+++ b/newlib/newlib.hin
@@ -90,6 +90,9 @@
 /* Define if using retargetable functions for default lock routines.  */
 #undef _RETARGETABLE_LOCKING
 
+/* Define if using the "legacy" 32 bit time_t */
+#undef _WANT_LONG_TIME_T
+
 /*
  * Iconv encodings enabled ("to" direction)
  */
--
2.7.4

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Changes the default size of time_t to 64 bit.

Freddie Chopin
On Fri, 2017-08-11 at 13:20 +0200, [hidden email] wrote:
> +`--enable-32bit-time_t'
> +     Use a time_t that is defined to long, regardless of the
> wordsize of
> +     the target. This may lead to problems in January 2038 when the
> 32 bit
> +     timestamp overflows but on the other hand may yield better
> +     performance than 64 bit timestamps.
> +     Disabled by default.

I would say that the option is misleading, as "long" may as well have
64-bits on 64-bit systems. Maybe it would be better to have it as "
--disable-64bit-time_t"? This would have a similar issue, but be
actually  more consistent with the logic of the patch - time_t is
either 64-bit or whatever "long" is.

Regards,
FCh
123
Loading...