Thank you. I've used the attached program to find the exact range of
bad values:
-67768038400752000 to -67768038400665600 (low to high)
(decode-time -67768038400752001) ; (- low 1)
(59 59 23 31 12 -2147481679 6 nil 0)
(decode-time -67768038400665599) ; (+ high 1)
(1 0 0 1 1 -2147481678 1 nil 0
Charles A. Roelli wrote:
Could we put a workaround for these "bad" values of time_t in gnulib
for this version of macOS?
Yes, we could. I started to write that, but it wasn't trivial. Eventually I hope
to get around to it.
The attached test program (time_test.c) enters an infinite loop when
run under macOS 10.6.
(compiled with: gcc -g3 time_test.c -o time_test.bin
run with: ./time_test.bin)
The localtime_r call has this backtrace:
(gdb) bt
#0 0x7fff83860ad3 in timesub () from /usr/lib/libSystem.B.dylib
#1
