Yo All! Looks like there are four cases to support with shmTime:
1: 64-bit time_t with 64-bit ints:
All known 64-bit distros (?)
Works after 2038
No change required.
2: 64-bit time_t with 32-bit ints:
All *BSD (?)
Works after 2038
No change required.
3: 32-bit time_t with 32-bit ints, No #define to get 64-bit time_t
glibc version 2.33 and before
Fails in 2038
No change possible
4: Optional 64-bit time_t with 32-bit ints. #define to get 64-bit time_t
glibc version 2.34 and later
Works after 2038
Incompatible with unmodified chrinyd, ntpd, htpshmmon, etc.
Fix possible.
So, looking only at option 4. The one that we can improve.
I had over looked the "int dummy[8]" in shmTime that Richard pointed out.
CUrrently gpsd has set those fields to 0.
In that case, and only that case, change shmTime as follows:
From:
struct shmTime
{
[...]
time_t receiveTimeStampSec;
[...]
int dummy[8];
};
To:
struct shmTime
{
[...]
// because we use 64-bit time_t, but ntpd expects 32-bits
// ignore the sign bit
int receiveTimeStampSec; // lower 31-bits of 64-bit time_t
[...]
// use the first dummy, previously zero
int top_time_t; // upper bits of 64-bit time_t
int dummy[7];
};
Before 2038, top_time_t will always be zero.
After 2038, until 2106, top_time_t will be always one.
That maintains compatibility with existing SHM users.
That works with existing SHM users until 2038.
That works with modified SHM users until the end of 64 bit time.
Thoughts?
No ideas about chronyd sockets yet.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpwMJMDm7uud.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
