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