✘64-bit time_t on glibc 2.34 and up

[Hal Murray]

gem at rellim.com said:
> Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit time_t on
> 32-bit Linux without much work.

> But...

> How to get that 2038 compatible time to ntpd and chronyd?  That is a much
> bigger problem. 


> This is a problem for glibc on 32 bits. And int is 32-bits, but time_t is a
> compile time option (32 or 64 bits).

> How does ntpd know what size time_t to use? And thus know the size of
> shmTime?  How do we know portably, preserving backwards and forwards
> compatibility? 

I'm missing the big picture.  I've been assuming that gpsd and ntpsec and 
everybody else will use time_t from the system header files.  (without 
tweaking anything)

I've been assuming the problem will just go away as distros that support 32 
bit systems will update their (default) time_t to 64 bits.

If 2038 rolls around and a distro is still using 32 bit time_t, gpsd is not 
going to be one of their major problems.

-----------


[Context was read-only SHM]
> Sadly, that no longer works on modern CPUs with out of order execution.
> Unless wrapped in a mutex, or atomic, and that is now a no-no.

I was assuming appropriate memory barriers.

What's no-no about atomics?

Mutexes seem complicated when shared by 2 programs.




-- 
These are my opinions.  I hate spam.