Yo Richard! On Fri, 13 Jan 2023 19:08:10 -0600 Richard Laager via devel <devel@ntpsec.org> wrote:
> > So, looking only at option 4. The one that we can improve.
>
> I think you have captured the options correctly.
Plus the corrections from Greg.
> > 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.
>
> I like it! In broad strokes, this seems like the right solution. Way
> better than my ideas about trying to use a magic and detect where it
> is.
Good.
> There is another time_t field in the struct. Does that also have to
> change?
Yeah. Missed that.
time_t clockTimeStampSec;
And:
time_t receiveTimeStampSec;
> Should top_time_t be unsigned?
Either way. The top bit is never set. I would like to follow
the existing as much as possible (time_t is int).
> The original 64-bit time_t will be
> signed, but you know that it is always positive. You put the lower 31
> bits in the original field (which makes sense, as you don't want the
> 32nd bit to go in the sign bit spot of the original field). That
> leaves 64 - 31 = 33 bits to save. One of those is the sign bit. Since
> we know it is positive, we can drop that. So top_time_t should be
> unsigned to make that clear.
I'll see what is easist to avoid compiler warnings with.
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
pgpyXBXpAxi4I.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
