You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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. Maybestruct timeval
could be used internally instead ofclock_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.The text was updated successfully, but these errors were encountered: