mktime loop

mktime loop

[Denis Excoffier]

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;
}
%

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

Re: mktime loop

[Corinna Vinschen]

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


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

Re: mktime loop

[Corinna Vinschen]

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


Corinna


(*) That's comparable with the off_t change from 4 to 8 byte we performed
    when switching from Cygwin 1.3 to 1.5, and it will be a helluvalot
    of work.  Given the work we still have to do to get a 64 bit distro
    up and running, this isn't exactly something I'm willing to invest a
    lot of time into this year.

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

Re: mktime loop

[Denis Excoffier]

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

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

Re: mktime loop

[Corinna Vinschen]

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

Re: mktime loop

[Denis Excoffier]

On 2013-05-14 15:39, Corinna Vinschen wrote:
> 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).
> 
I can confirm that the last snapshot (20130516) fixes the problem.

Thank you.

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