g...@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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
