Does this problem go away (for another 68 years) if on 32 bit systems, we change the time_t in SHM to uint32_t?
The SHM layout stays the same so all combinations of old/new will continue to work today. When the top bit turns on in 2038, recent builds will fill with 0s rather than sign extend when converting to a 64 bit time_t which is what we want. Old code using SHM and 32 bit time_t will do whatever in 2038. I hope any interesting code will be recompiled by then. (Will we still be running Intel instruction sets? ARM?) If there is enough code that hasn't been updated, it wouldn't surprise me if somebody added a hack that said something like dates older than 1950 are really next era sp add 0x100000000 seconds when converting to text. -------- There is a potential problem. If a 32 bit OS/Distro has already converted to 64 bit time_t then we will break things if we convert to uint32_t. So the decision to switch from time_t to uint32_t is more complicated that are we running on a 32 bit system. How many 32 bit OSes do we run on? 32 bit Linux/Debian has 32 bit time_t on i686 32 bit FreeBSD has 32 bit time_t on i386 32 bit FreeBSD has 64 bit time_t on armv7 and armv6 32 bit NetBSD has 64 bit time_t on Intel and Pi 2 I didn't check older but still supported versions. ------ In case nobody noticed, I hacked a sizeof(time_t) into NTPsec's configuration stuff a while ago. So you can get the answer by looking in a handy config.h -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
