Re: ✘64-bit time_t on glibc 2.34 and up

[Hal Murray]

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.