time_t is 64-bit in amd64

[wehimwich]

This causes a conflict between 32- and 64-bit operation in fixed length data structures in C and values passed to FORTRAN. This will need to be fully resolved before 2038, only 19 years away.

Short term:

• A change in declarations of passed in pointers in rtelb from time_t to int and changes to pass pointers to int to the same routines (and then conversion of results to time_t) in fmset is probably sufficient for now. This is implemented. It needs to be tested in setcl and fmset for:

• 5B

• RDBE

• FiLa10G

• Mark IV

• S2 (no longer possible)

• VLBA (no longer possible)

• Use of the rtelb routines in FORTRAN needs to be checked.

Longer term:

• The use of the int array centisec in dbbcn, rdbcn, mk5cn, (other...cn?), fmset, and setcl (and chekr?) and perhaps others can probably be easily rewritten to use a structure with time_t in C code.

• The use in FORTRAN code will be tricker since there needs to be integer4 and integer8 for 32- and 64-bit respectively, and that will also affect the data structure lay-out. Are FORTRAN structures an option?

• In principle for model computer there is no need to have the time since boot limited to 248 days. For 64-bit systems this limit will be expanded beyond being a practical constraint (248 days already seemed long enough for that), but maybe the time code could be restructured to avoid this even on 32-bit systems. Maybe struct timeval could be used internally instead of clock_t to represent ticks, but that seems excessive Maybe a 64-bit int is good enough. There is a related issue day 248 time problem not checked when time model is 'computer' #56.