winsup/cygwin/libc/strptime.cc(__strptime) strptime %F issue
Sat Sep 2 14:17:00 GMT 2017
On Aug 29 18:09, Brian Inglis wrote:
> On 2017-08-29 13:14, Corinna Vinschen wrote:
> > On Aug 29 11:56, Brian Inglis wrote:
> >> got diverted during strptime testing due to time functions gmtime,
> >> localtime, mktime, strftime not properly handling struct
> >> tm->tm_year == INT_MAX => year == INT_MAX + 1900 so year needs to
> >> be at least long in Cygwin 64,
That's not possible. struct tm members are int per POSIX. Values
beyond INT_MIN/INT_MAX are simply out of bounds.
> >> also affecting tzcalc_limits, and
> >> depending on what is required to properly handle time_t in Cygwin
> >> 32.
> > Sounds like you're busy with time functions for a while ;)
> If either long or long long will fix both Cygwin 64 and 32 time_t and
> struct tm, patches should not be long coming to a bunch of newlib time
time_t == long == 64 bit on Cygwin 64
This will not change at all, of course, but...
time_t == long == 32 bit on Cygwin 32
This won't change anytime soon. Just try to figure out how many
structures (e.g., struct stat, struct timeval) and functions are
affected. If we really want to change Cygwin 32 to use a 64 bit time_t,
we either have an excessive lot of work to keep backward compatibility
with existing apps, or we send the entire current 32 bit distro into
pension and perform a backward incompatible bulk rebuild with 64 bit
time_t. The latter would probably be the better approach.
Alternatively we just let Cygwin 32 bit as is and wait for my own
pension which will be earlier than 2038...
> Thanks. Enjoy your vacay.
Will do, thanks,
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Cygwin-patches