Michael G Schwern wrote:
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.
I may be a bit behind on applying eco's (bugfixes) to my home system.
I did find and report to HP/VMS that one of the header files was using
an unsigned int instead of time_t back when I was investigating the
Archive::Tar issues with VMS.
-John
[EMAIL PROTECTED]
Personal Opinion Only
