✘64-bit time_t on glibc 2.34 and up
Hal Murray
halmurray at sonic.net
Sat Jan 14 16:30:08 UTC 2023
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.
More information about the devel
mailing list