Michael G Schwern wrote:
> John E. Malmberg wrote:
>> Michael G Schwern wrote:
>>> John E. Malmberg wrote:
>>>> Default:
>>>>
>>> Thanks, that looks all correct. If you could try the latest version
>>> of the
>>> code that would be great. It makes it more accurate for systems which
>>> have
>>> silly failure points, like Y10K.
>>> http://code.google.com/p/y2038/source/browse/trunk/bin/check_max.c
>> EAGLE> cc check_max
>> EAGLE> link check_max
>> EAGLE> run check_max
>> gmtime max 4294967295
>> localtime max 4294967295
>> gmtime min 0
>> localtime min 0
>>
>> EAGLE> cc check_max/define=__SIGNED_INT_TIME_T
>> EAGLE> link check_max
>> EAGLE> run check_max
>> gmtime max 2147483647
>> localtime max 2147483647
>> gmtime min 3221225472
>> localtime min 3221225472
>
> Well that's unsettling. Any ideas?
I've dusted off my OpenVMS testdrive account and tried the repaired
check_max.c and got...
$ cc check_max
$ link check_max
$ run check_max
gmtime max 4294967295
localtime max 4294967295
gmtime min 0
localtime min 0
$ cc check_max/define=__SIGNED_INT_TIME_T
$ link check_max
$ run check_max
gmtime max 2147483647
localtime max 2147483647
gmtime min 0
localtime min 0
Which, as it turns out, is correct because...
bash$ test_date -1
input: -1, time: -1
localtime(-1): Sun Feb 7 01:28:15 2106
gmtime(-1): Sun Feb 7 06:28:15 2106
Whoopsie. I'd imagine tm.tm_year remains unsigned.
--
The mind is a terrible thing,
and it must be stopped.
