This is the mail archive of the
mailing list for the Cygwin project.
Re: mktime loop
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 14 May 2013 15:39:50 +0200
- Subject: Re: mktime loop
- References: <5244063b734b165baf34bdebaff0aca5 at denis-excoffier dot org> <20130513153651 dot GD5045 at calimero dot vinschen dot de> <20130513154921 dot GF8890 at calimero dot vinschen dot de> <27BBE8FE-303A-432D-94AA-AF834124D125 at Denis-Excoffier dot org> <20130513165712 dot GH8890 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
On May 13 18:57, Corinna Vinschen wrote:
> On May 13 18:41, Denis Excoffier wrote:
> > On 2013-05-13 17:49, Corinna Vinschen wrote:
> > > Erm... hang on. Is that really a problem? 2147483647 is 0x7fffffff,
> > > which is the maximum you get with a 4 byte time_t (== signed long)
> > > anyway. If you switch the date to 2038-01-20, the value will be
> > > negative, and therefore outside the scope of the 4 byte time_t. So this
> > > is a hard restriction of using 4 byte time_t.
> > >
> > > The solution is:
> > >
> > > - Either somebody changes 32 bit Cygwin to 8 byte time_t while keeping
> > > all the 4 byte time_t APIs intact to maintain compatibility with
> > > existing binaries(*),
> > >
> > > - or, you switch to a 64 bit Windows and use 64 bit Cygwin ;)
> > >
> > I understand.
> > I suppose you will however be willing to provide us a means to workaround
> > the "autoconf mktime usability test failing" (see for example in
> > gawk-4.1.0 where all the tm fields are set to 128). Now, instead of only
> > failing (i presume), it hangs. Sorry, this specific point should have been
> > noticed in my original post.
> > Or do we have to patch every impacted ./configure?
> Good point. I guess the right thing to do here is for mktime to
> return -1 instead of hanging. I look into that.
Looks like this is a result of gcc optimization settings. The upstream
code computing time_t <-> struct tm conversions requires integer
overflow to be fully defined, but gcc's -O2 option sets
-fstrict-overflow which results in all kinds of agressive integer
optimizations which disabled utilizing integer overflows for serious
purposes. I fixed that by setting the -fwrapv option when building the
affected localtime.cc file (thanks to Kai Tietz for pointing this out).
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple