Eryk Sun added the comment:
To resolve the crash on Windows in 2.7 requires backporting checktm(). Using
asctime_s doesn't solve the problem. The CRT still calls the default invalid
parameter handler, which kills the process -- as shown by the following ctypes
example:
from ctypes import *
libc = CDLL('msvcr90')
class tm(Structure):
_fields_ = (('tm_sec', c_int),
('tm_min', c_int),
('tm_hour', c_int),
('tm_mday', c_int),
('tm_mon', c_int),
('tm_year', c_int),
('tm_wday', c_int),
('tm_yday', c_int),
('tm_isdst', c_int))
libc._localtime32.restype = POINTER(tm)
libc.asctime_s.restype = c_char_p
t = c_int()
libc._time32(byref(t))
lt = libc._localtime32(byref(t))
sbuf = (c_char * 100)()
>>> libc.asctime_s(sbuf, sizeof(sbuf), lt)
>>> sbuf.value
'Sun Jun 26 19:22:47 2016\n'
>>> lt[0].tm_hour = -1
>>> libc.asctime_s(sbuf, sizeof(sbuf), lt)
Breakpoint 0 hit
MSVCR90!_invoke_watson:
00000000`6b8950e4 4053 push rbx
0:000> k5
Child-SP RetAddr Call Site
00000000`005ef628 00000000`6b8952d4 MSVCR90!_invoke_watson
00000000`005ef630 00000000`6b859830 MSVCR90!_invalid_parameter+0x70
00000000`005ef670 00000000`1d1aff53 MSVCR90!asctime_s+0x2fc
00000000`005ef6b0 00000000`1d1ae7fc _ctypes!ffi_call_AMD64+0x77
00000000`005ef700 00000000`1d1aa4c6 _ctypes!ffi_call+0x8c
----------
nosy: +eryksun
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16137>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
