Introduction and 64 bit time_t

Introduction and 64 bit time_t

[Philipp.Trommler]

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

Re: Introduction and 64 bit time_t

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1703 bytes --]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Introduction and 64 bit time_t

[Joel Sherrill]

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

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Philipp.Trommler]

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
> 

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

On Aug  9 12:17, Philipp.Trommler@preh.de 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Freddie Chopin]

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

Re: Introduction and 64 bit time_t

[Philipp.Trommler]

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

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Aug  9 13:47, Philipp.Trommler@preh.de 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Aug  9 13:47, Philipp.Trommler@preh.de 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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?

Re: Introduction and 64 bit time_t

[Freddie Chopin]

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

Re: Introduction and 64 bit time_t

[Joel Sherrill]

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

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Sebastian Huber]

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  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

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

Re: Introduction and 64 bit time_t

[philipp.trommler]

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

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

[philipp.trommler]

From: Philipp Trommler <philipp.trommler@preh.de>

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 <philipp.trommler@preh.de>
---
 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

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

[Freddie Chopin]

On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de 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

Re: Introduction and 64 bit time_t

[Freddie Chopin]

On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de wrote:
> 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?

As the author of the patch that changed gmtime_r() I think I may chime
in.

The cast in question is just copied from the older version of this
function - _mktm_r() - you may see that in the git history. Why the
cast is there - I have no idea... If you would ask me, I would say to
just remove it.

"days" and "rem" variables can be both changed to time_t.

Regards,
FCh

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Aug 11 14:23, Freddie Chopin wrote:
> On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de 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.

what about something like --enable-time_t-is-long-only ?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Aug 11 14:38, Freddie Chopin wrote:
> On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de wrote:
> > 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?
> 
> As the author of the patch that changed gmtime_r() I think I may chime
> in.
> 
> The cast in question is just copied from the older version of this
> function - _mktm_r() - you may see that in the git history. Why the
> cast is there - I have no idea... If you would ask me, I would say to
> just remove it.
> 
> "days" and "rem" variables can be both changed to time_t.

ACK.  Any 'long' in the time code should be replaced with time_t,
and useless casts removed.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Philipp.Trommler]

Am Freitag, den 11.08.2017, 15:40 +0200 schrieb Corinna Vinschen:
> On Aug 11 14:23, Freddie Chopin wrote:
> > 
> > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de 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.
> what about something like --enable-time_t-is-long-only ?

I'd personally prefer that, even though it's quite long. The whole bit-
ness is confusing in my opinion when it comes to non-fixed-with types
such as long.
I'll adopt my patch.

Philipp

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

On Aug 11 15:40, Corinna Vinschen wrote:
> On Aug 11 14:23, Freddie Chopin wrote:
> > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de 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.
> 
> what about something like --enable-time_t-is-long-only ?

Alternatively, what about sticking to --enable-32bit-time_t and mean it?

We could define time_t as __int32_t or __int_least32_t then, rather
than using long.  The definition of time_t is then actually controlled
by a concious decision of the developer.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Philipp.Trommler]

Am Freitag, den 11.08.2017, 15:42 +0200 schrieb Corinna Vinschen:
> On Aug 11 14:38, Freddie Chopin wrote:
> > 
> > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de wrote:
> > > 
> > > 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?
> > As the author of the patch that changed gmtime_r() I think I may
> > chime
> > in.
> > 
> > The cast in question is just copied from the older version of this
> > function - _mktm_r() - you may see that in the git history. Why the
> > cast is there - I have no idea... If you would ask me, I would say
> > to
> > just remove it.
> > 
> > "days" and "rem" variables can be both changed to time_t.
> ACK.  Any 'long' in the time code should be replaced with time_t,
> and useless casts removed.

I'll do this and post a patch afterwards.

Philipp

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Aug 11 13:20, philipp.trommler@preh.de wrote:
> From: Philipp Trommler <philipp.trommler@preh.de>
> 
> 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.
> [...]
> 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 */

You know, this is kind of funny :)

You may want to clarify the discrepancy of USE_LONG vs. "use short"

>  #define	_TIME_T_	long		/* time() */

https://sourceware.org/ml/newlib/2017/msg00776.html


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Philipp.Trommler]

Am Freitag, den 11.08.2017, 15:47 +0200 schrieb Corinna Vinschen:
> On Aug 11 15:40, Corinna Vinschen wrote:
> > 
> > On Aug 11 14:23, Freddie Chopin wrote:
> > > 
> > > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de
> > > 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.
> > what about something like --enable-time_t-is-long-only ?
> Alternatively, what about sticking to --enable-32bit-time_t and mean
> it?
> 
> We could define time_t as __int32_t or __int_least32_t then, rather
> than using long.  The definition of time_t is then actually
> controlled
> by a concious decision of the developer.

While I like the idea of a concious decision, the benefit of something
like --enable-time_t-is-long-only and defining it to long is that
keeping compatibility is a no-brainer for the users. They get exactly
what they were used to, including the changes from long to time_t in
the whole time code.

Philipp

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

On Aug 11 13:53, Philipp.Trommler@preh.de wrote:
> Am Freitag, den 11.08.2017, 15:47 +0200 schrieb Corinna Vinschen:
> > On Aug 11 15:40, Corinna Vinschen wrote:
> > > 
> > > On Aug 11 14:23, Freddie Chopin wrote:
> > > > 
> > > > On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de
> > > > 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.
> > > what about something like --enable-time_t-is-long-only ?
> > Alternatively, what about sticking to --enable-32bit-time_t and mean
> > it?
> > 
> > We could define time_t as __int32_t or __int_least32_t then, rather
> > than using long.  The definition of time_t is then actually
> > controlled
> > by a concious decision of the developer.
> 
> While I like the idea of a concious decision, the benefit of something
> like --enable-time_t-is-long-only and defining it to long is that
> keeping compatibility is a no-brainer for the users. They get exactly
> what they were used to, including the changes from long to time_t in
> the whole time code.

I think "no-brainer" is not the right word here.  The developer of a 32
bit system will now always get 64 bit time_t, unless she explicitely
uses --enable-something-with-time_t.  Since there's a decision to make
anyway, we can just as well make sure that the developer gets exactly
what she's asking for.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Introduction and 64 bit time_t

[Brian Inglis]

On 2017-08-09 06:35, Corinna Vinschen wrote:

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

But may not be long enough for system users, as the GPS 1024 week wraparound on
1999 Aug 22 (the next one is 2019 Apr 7!), and Y2K, demonstrated.
Many embedded systems were scrapped and replaced, some only a few years old, as
nobody wanted to or could maintain them, because managers and developers did not
expect to be at those companies and/or their systems to be around in 2000.
Given 38 years warning of the issue and the changes since then, I am shocked
(but not surprised) anyone is still using 32 bit signed time_t.

OT: I remember Kent Pitman posting an apology for an MIT EMACS modeline TECO
date macro Y2K bug, that had not been changed in a few decades:
https://groups.google.com/d/msg/alt.lang.teco/pvmo3Ppm6Uk/7ScAYTLukekJ

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Re: Introduction and 64 bit time_t

[Brian Inglis]

On 2017-08-09 06:35, Corinna Vinschen wrote:

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

But may not be long enough for system users, as the GPS 1024 week wraparound on
1999 Aug 22 (the next one is 2019 Apr 7!), and Y2K, demonstrated.
Many embedded systems were scrapped and replaced, some only a few years old, as
nobody wanted to or could maintain them, because managers and developers did not
expect to be at those companies and/or their systems to be around in 2000.
Given 38 years warning of the issue and the changes since then, I am shocked
(but not surprised) anyone is still using 32 bit signed time_t.

OT: I remember Kent Pitman posting an apology for an MIT EMACS modeline TECO
date macro Y2K bug, that had not been changed in a few decades:
https://groups.google.com/d/msg/alt.lang.teco/pvmo3Ppm6Uk/7ScAYTLukekJ

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

[Jeff Johnston]

On Fri, Aug 11, 2017 at 8:23 AM, Freddie Chopin <freddie_chopin@op.pl> wrote:
> On Fri, 2017-08-11 at 13:20 +0200, philipp.trommler@preh.de 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.
>

What about: --enable-time_t-compat to indicate it is a compat-type option
indicating old behaviour?

> Regards,
> FCh

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

[Hans-Bernhard Bröker]

Am 11.08.2017 um 22:15 schrieb Jeff Johnston:

> What about: --enable-time_t-compat to indicate it is a compat-type option
> indicating old behaviour?

That would violate rule-for-naming-things #1: never distinguish between 
two stages of development of something by naming one of them "new", or 
the other one "old".  If you do, you'll end up having to explain what 
the difference between really-very-new and 
brand-spanking-really-very-new actually is, and having no idea how to do 
that.

IMHO, the name of that option absolutely has to contain explicit mention 
of "32 bits", because its entire reason to exist is to make time_t 32 
bits.  Whether the actual time_t typedef then ends up being int, long, 
int_least32_t or what-not is of no interested to the person using that 
option, so has no business appearing in the option name.

The only alternative option syntax I might find acceptable would be 
something like --enable-time_t_override=<typename>, but only if 
configure can be taught to check that <typename> is actually a viable 
choice.

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

[Joel Sherrill]

On 8/11/2017 3:58 PM, Hans-Bernhard Bröker wrote:
> Am 11.08.2017 um 22:15 schrieb Jeff Johnston:
> 
>> What about: --enable-time_t-compat to indicate it is a compat-type option
>> indicating old behaviour?
> 
> That would violate rule-for-naming-things #1: never distinguish between
> two stages of development of something by naming one of them "new", or
> the other one "old".  If you do, you'll end up having to explain what
> the difference between really-very-new and
> brand-spanking-really-very-new actually is, and having no idea how to do
> that.

+1 RTEMS still has a directory named "new-exceptions" which is now probably
fifteen years old. :(
  
> IMHO, the name of that option absolutely has to contain explicit mention
> of "32 bits", because its entire reason to exist is to make time_t 32
> bits.  Whether the actual time_t typedef then ends up being int, long,
> int_least32_t or what-not is of no interested to the person using that
> option, so has no business appearing in the option name.
> 
> The only alternative option syntax I might find acceptable would be
> something like --enable-time_t_override=<typename>, but only if
> configure can be taught to check that <typename> is actually a viable
> choice.
> 

I lean to making it clear you are forcing 32 or 64 bits.

--joel
RTEMS

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

[Freddie Chopin]

On Fri, 2017-08-11 at 15:47 +0200, Corinna Vinschen wrote:
> Alternatively, what about sticking to --enable-32bit-time_t and mean
> it?
> 
> We could define time_t as __int32_t or __int_least32_t then, rather
> than using long.  The definition of time_t is then actually
> controlled
> by a concious decision of the developer.

+1 from me (;

Regards,
FCh

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

[Sebastian Huber]

----- Freddie Chopin <freddie_chopin@op.pl> schrieb:
> On Fri, 2017-08-11 at 15:47 +0200, Corinna Vinschen wrote:
> > Alternatively, what about sticking to --enable-32bit-time_t and mean
> > it?
> > 
> > We could define time_t as __int32_t or __int_least32_t then, rather
> > than using long.  The definition of time_t is then actually
> > controlled
> > by a concious decision of the developer.
> 
> +1 from me (;
> 
> Regards,
> FCh

Such a type change may break binary compatibility due to C++ name mangling.

-- 
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  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine gesch&auml;ftliche Mitteilung im Sinne des EHUG.

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

[Freddie Chopin]

On Sat, 2017-08-12 at 11:49 +0200, Sebastian Huber wrote:
> Such a type change may break binary compatibility due to C++ name
> mangling.

Bump version of newlib to 3 and "problem solved" (; . While doing that
we may also remove some ancient stuff kept in _reent (and probably some
other places) for compatibility.

Regards,
FCh

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

[Philipp.Trommler]

Hi!

The threading here got a little out of hand, I try to summarize the
discussion here (the longest thread):

1. Newlib should use a 64 bit sized time_t by default.
2. All usage of long within the time directory should be replaced by 
   time_t.
3. There should be a configure option to either
   a) use a long as before or
   b) use a fixed size 32 bit integer.
4. The configure option should either
   a) contain the phrase 32 bit or
   b) contain something like compat.

The discussion led my to the point where I'd prefer 3. b) and 4. a) but
I don't feel like I'm in the position to decide that.

Regards
Philipp


Am Samstag, den 12.08.2017, 13:40 +0200 schrieb Freddie Chopin:
> On Sat, 2017-08-12 at 11:49 +0200, Sebastian Huber wrote:
> > 
> > Such a type change may break binary compatibility due to C++ name
> > mangling.
> Bump version of newlib to 3 and "problem solved" (; . While doing
> that
> we may also remove some ancient stuff kept in _reent (and probably
> some
> other places) for compatibility.
> 
> Regards,
> FCh
> 
> 

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Aug 12 11:49, Sebastian Huber wrote:
> 
> ----- Freddie Chopin <freddie_chopin@op.pl> schrieb:
> > On Fri, 2017-08-11 at 15:47 +0200, Corinna Vinschen wrote:
> > > Alternatively, what about sticking to --enable-32bit-time_t and mean
> > > it?
> > > 
> > > We could define time_t as __int32_t or __int_least32_t then, rather
> > > than using long.  The definition of time_t is then actually
> > > controlled
> > > by a concious decision of the developer.
> > 
> > +1 from me (;
> > 
> > Regards,
> > FCh
> 
> Such a type change may break binary compatibility due to C++ name mangling.

Very good point.

If int32_t is defined as int, we get an i rather than an l in the mangled
name of C++ methods/functions.

The same goes for using int64_t vs. long and int64_t vs. long long which
changes the l to an x.

So we have to maintain the type "long" for backward compatibility
an all systems which require backward compat.  64 bit Cygwin works
with 'int64_t' since it's == long, but 32 bit Cygwin would be broken
by using int32_t because it's defined as int.

I don't know for other systems.  But the point is, by changing to
64 bit time_t we break backward compat for all systems with 32 bit long
anyway.  However, the --enable-32bit_time_t option should use 'long'
in the first place.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Sebastian Huber]

----- Am 14. Aug 2017 um 10:17 schrieb Corinna Vinschen vinschen@redhat.com:
[...]
> I don't know for other systems.  But the point is, by changing to
> 64 bit time_t we break backward compat for all systems with 32 bit long
> anyway.  However, the --enable-32bit_time_t option should use 'long'
> in the first place.

What about --enable-long-time_t with enough words in the documentation to explain this properly?

Defines time_t to long. On platforms with a 32-bit long type this gives raise to the year 2038 problem.  This option is not the default.  The default type for time_t is a signed 64-bit integer.

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

[Freddie Chopin]

On Mon, 2017-08-14 at 10:46 +0200, Sebastian Huber wrote:
> What about --enable-long-time_t with enough words in the
> documentation to explain this properly?

Maybe "--disable-long-long-time_t" would be more intuitive?

Regards,
FCh

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On Aug 14 10:46, Sebastian Huber wrote:
> 
> 
> ----- Am 14. Aug 2017 um 10:17 schrieb Corinna Vinschen vinschen@redhat.com:
> [...]
> > I don't know for other systems.  But the point is, by changing to
> > 64 bit time_t we break backward compat for all systems with 32 bit long
> > anyway.  However, the --enable-32bit_time_t option should use 'long'
> > in the first place.
> 
> What about --enable-long-time_t with enough words in the documentation
> to explain this properly?
> 
> Defines time_t to long. On platforms with a 32-bit long type this
> gives raise to the year 2038 problem.  This option is not the default.
> The default type for time_t is a signed 64-bit integer.

I was leaning towards enabling this option so that the type is always
32 bit.  I.e., use long on 32 bit systems but, say, int32_t on 64 bit
system.

If that makes sense at all.  If not, fine with me.

In terms of the C++ ABI, we should really use the type "long" for 64 bit
systems as well by default, if long is a 64 bit type.  You never know if
the int_XXX64_t types are not defined as 'long long' and then break the
ABI again.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Sebastian Huber]

----- Am 14. Aug 2017 um 11:04 schrieb Freddie Chopin freddie_chopin@op.pl:

> On Mon, 2017-08-14 at 10:46 +0200, Sebastian Huber wrote:
>> What about --enable-long-time_t with enough words in the
>> documentation to explain this properly?
> 
> Maybe "--disable-long-long-time_t" would be more intuitive?

Why should be time_t of type long long on an LP64 target?

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

[Freddie Chopin]

On Mon, 2017-08-14 at 11:47 +0200, Sebastian Huber wrote:
> ----- Am 14. Aug 2017 um 11:04 schrieb Freddie Chopin freddie_chopin@
> op.pl:
> 
> > On Mon, 2017-08-14 at 10:46 +0200, Sebastian Huber wrote:
> > > What about --enable-long-time_t with enough words in the
> > > documentation to explain this properly?
> > 
> > Maybe "--disable-long-long-time_t" would be more intuitive?
> 
> Why should be time_t of type long long on an LP64 target?

The whole discussion is not about LP64 target, but about making time_t
64-bit on 32-bit platforms. For them, time_t should be set to "long
long" or "int64_t" to achieve that goal.

The problem I see with "--enable-long-time_t" is that for me it seems
that opposite option has "short" instead of "long", while in this case
it will be "long long".

Regards,
FCh

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

[Philipp.Trommler]

Hi,

sorry for the late response, I've been quite busy the last days.

Do we have reached any consensus on the logic to use for the configure
parameter (enable-32bit vs. disable-64bit) and the type to use for
time_t (long on 64bit, long long on 32bit vs. fixed width types)?

I'll be unavailable the next two weeks but I'd like to adopt my patch
to that consensus afterwards.

Regards
Philipp


Am Montag, den 14.08.2017, 13:14 +0200 schrieb Freddie Chopin:
> On Mon, 2017-08-14 at 11:47 +0200, Sebastian Huber wrote:
> > 
> > ----- Am 14. Aug 2017 um 11:04 schrieb Freddie Chopin
> > freddie_chopin@
> > op.pl:
> > 
> > > 
> > > On Mon, 2017-08-14 at 10:46 +0200, Sebastian Huber wrote:
> > > > 
> > > > What about --enable-long-time_t with enough words in the
> > > > documentation to explain this properly?
> > > Maybe "--disable-long-long-time_t" would be more intuitive?
> > Why should be time_t of type long long on an LP64 target?
> The whole discussion is not about LP64 target, but about making
> time_t
> 64-bit on 32-bit platforms. For them, time_t should be set to "long
> long" or "int64_t" to achieve that goal.
> 
> The problem I see with "--enable-long-time_t" is that for me it seems
> that opposite option has "short" instead of "long", while in this
> case
> it will be "long long".
> 
> Regards,
> FCh
> 
> 

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

[Sebastian Huber]

Currently we have:

#define    _TIME_T_    long        /* time() */

If we change this type, it is probably nice to add a configure option to 
restore this definition for those who trade off binary compatibility 
with a year 2038 readiness.

I am still in favour of --enable-long-time_t, since this corresponds 
exactly to the current definition.

We should make the type change only if necessary, e.g. something like this:

#if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL

#define _TIME_T_ long

#else

#define _TIME_T_ __int_least64_t

#endif


-- 
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  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Aug 25 08:15, Sebastian Huber wrote:
> Currently we have:
> 
> #define    _TIME_T_    long        /* time() */
> 
> If we change this type, it is probably nice to add a configure option to
> restore this definition for those who trade off binary compatibility with a
> year 2038 readiness.
> 
> I am still in favour of --enable-long-time_t, since this corresponds exactly
> to the current definition.
> 
> We should make the type change only if necessary, e.g. something like this:
> 
> #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL
> 
> #define _TIME_T_ long
> 
> #else
> 
> #define _TIME_T_ __int_least64_t
> 
> #endif

Fine with me, unless Cygwin.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Sebastian Huber]

On 25/08/17 14:06, Corinna Vinschen wrote:

> On Aug 25 08:15, Sebastian Huber wrote:
>> Currently we have:
>>
>> #define    _TIME_T_    long        /* time() */
>>
>> If we change this type, it is probably nice to add a configure option to
>> restore this definition for those who trade off binary compatibility with a
>> year 2038 readiness.
>>
>> I am still in favour of --enable-long-time_t, since this corresponds exactly
>> to the current definition.
>>
>> We should make the type change only if necessary, e.g. something like this:
>>
>> #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL
>>
>> #define _TIME_T_ long
>>
>> #else
>>
>> #define _TIME_T_ __int_least64_t
>>
>> #endif
> Fine with me, unless Cygwin.

We should probably add this to <sys/config.h>:

#ifdef _WANT_USE_LONG_TIME_T
#ifndef _USE_LONG_TIME_T
#define _USE_LONG_TIME_T
#endif
#endif

The _WANT_USE_LONG_TIME_T is defined by --enable-long-time_t. Cygwin (or 
any other system) can use <cygwin/config.h> to define _USE_LONG_TIME_T. 
Is this ok?

-- 
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  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Aug 25 14:14, Sebastian Huber wrote:
> On 25/08/17 14:06, Corinna Vinschen wrote:
> 
> > On Aug 25 08:15, Sebastian Huber wrote:
> > > Currently we have:
> > > 
> > > #define    _TIME_T_    long        /* time() */
> > > 
> > > If we change this type, it is probably nice to add a configure option to
> > > restore this definition for those who trade off binary compatibility with a
> > > year 2038 readiness.
> > > 
> > > I am still in favour of --enable-long-time_t, since this corresponds exactly
> > > to the current definition.
> > > 
> > > We should make the type change only if necessary, e.g. something like this:
> > > 
> > > #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL
> > > 
> > > #define _TIME_T_ long
> > > 
> > > #else
> > > 
> > > #define _TIME_T_ __int_least64_t
> > > 
> > > #endif
> > Fine with me, unless Cygwin.
> 
> We should probably add this to <sys/config.h>:
> 
> #ifdef _WANT_USE_LONG_TIME_T
> #ifndef _USE_LONG_TIME_T
> #define _USE_LONG_TIME_T
> #endif
> #endif
> 
> The _WANT_USE_LONG_TIME_T is defined by --enable-long-time_t. Cygwin (or any
> other system) can use <cygwin/config.h> to define _USE_LONG_TIME_T. Is this
> ok?

Sounds good to me.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]