Menu
▾
▴
#557 Fix year 2038 problems
Programs compiled with file.bi or vbcompat.bi that use the FileDateTime() function crash unexpectedly will a memory error when a file older than 2039 is accessed. I tried timestamps of Jan 1, 2038 at midnight and the function works. I tried it with timestamps of Jan 1, 2039 at midnight and the programs crash with Application Event ID 1000 in Windows Application Event Log.
I used TOUCH.exe from one of the MS Server Resource Kits to set "last modify time" time stamps for testing. I initially found this bug when trying to list all file names, file sizes and file timestamps for a complete volume. 14 TB volume had 300,000 + files, some with wacky timestamps (2050, 2098, etc.).
FileDateTime() should be made to work for the entire range of timestamps that NTFS can store.
There appear to be two problems to address here:
1) The crash in the FB runtime if the system time somehow can't be retrieved or interpreted
2) The current limitation to 32bit (see also year 2038 problem)
The crash appears to have the same cause as similar ones that I worked on not long ago; it's easy to fix but introduces an error return value for the affected function(s). Instead of crashing, FileDateTime() will now just return a zero date serial, which maps to 1970-1-1, which I realize isn't a nice solution but I don't see an alternative (this is the same fix as was previously applied to other time/date functions, funny I missed this one).
Removing the 32bit limitation could be as easy as switching to using the 64bit system functions (I think at least on Windows' MSVCRT and Linux' glibc there are 64bit versions of the common time functions, even on 32bit systems), if just I knew whether the FB date serial mechanism worked with it... I might give it a try; besides that it can probably also wait until FB is ported to 64bit.
The 10/31 posting implied that a change has been made to Freebasic to at least provide a result code as a work around. At present, programs compiled with FreeBasic bomb upon hitting a date that's beyond the abilities of the 32bit date system. It would be a great improvement simply to have this fix. If a patch is available, how does one acquire it?
At the moment the patch is available (only) in the development version of FreeBASIC, which can be recompiled with MinGW/MSYS installed.
I'm not sure whether there are any "Git daily builds" available right now, but other than that... the next FB release probably will be next year. Although... a 0.23.1 bug fix update, that might be something worth looking at...