mktime loop

Denis Excoffier cygwin@Denis-Excoffier.org
Mon May 13 16:41:00 GMT 2013


On 2013-05-13 17:49, Corinna Vinschen wrote:
> On May 13 17:36, Corinna Vinschen wrote:
>> On May 13 09:08, Denis Excoffier wrote:
>>> Hello,
>>> 
>>> The following program (see below) is working properly under plain
>>> 1.7.18. With all the snapshots afterwards (including
>>> the current one 20130508), it fails after day=19, looping forever
>>> (it seems). I use XP.
>>> 
>>> Regards,
>>> 
>>> Denis Excoffier.
>>> 
>>> % cat foo.c
>>> #include <stdio.h>
>>> #include <time.h>
>>> 
>>> int
>>> main ()
>>> {
>>>  int day;
>>>  // date --date='@2147483647' +%Y-%m-%d gives 2038-01-19
>>>  for ( day = 1 ; day <= 31 ; ++day ) {
>>>    struct tm tm;
>>>    time_t now;
>>>    tm.tm_year = 2038 - 1900;
>>>    tm.tm_mon = 1 - 1;
>>>    tm.tm_mday = day; // 19, 20
>>>    tm.tm_hour = 0;
>>>    tm.tm_min = 0;
>>>    tm.tm_sec = 0;
>>>    now = mktime (&tm);
>>>    fprintf (stderr, "day=%d\n", day);
>>>  };
>>>  return 0;
>>> }
>> 
>> Thanks for the testcase.  This looks like the new BSD code I added
>> lately assumes that the datatype time_t is 8 bytes, not 4 byte as on 32
>> bit Cygwin.  That's just a hunch I take from the fact that your testcase
>> works fine on 64 bit Cygwin and only hangs on 32 bit Cygwin.  Oh well.
>> I'll investigate further...
> 
> 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?

Regards,

Denis Excoffier.

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



More information about the Cygwin mailing list