New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Review]Fix the potential 2038 issues #7466
Conversation
There are also the reverse situation platforms with 64 bit |
Did you verify this patch on a system with 32 bit |
The win 64-bit use an abstract data model called LLP64 (or P64). |
I was not referring to Windows. I'm pretty sure (early?) AIX versions work like I explained. |
The length of long in a 32-bit system is 32 bits, which cannot be used to save timestamps after 2038. Most operating systems have extended time_t to 64 bits. This changes is to replace the operation of casting to long with casting to time_t.
If AIX is posix compatible system, I think my PR don't introduce a new issue even if the platform is 64-bit long and 32-bit time_t. |
Thanks! |
Most operating systems have extended time_t to 64 bits.
Possible loss of data caused by the following code:
The code
now.tv_sec = (long)time(NULL);
This changes is to remove the operation of casting to long.