This is the mail archive of the
cygwin
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple