mktime loop

[Corinna Vinschen]

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.


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