Achim Gratz <strom...@nexgo.de>: > Hal Murray writes: > > hmur...@megapathdsl.net said: > >> There is an implicit assumption that the two (l_fp) times that you subtract > >> are in the same epoch. > > > > Argh. That's wrong. It works across the epoch boundary. The requirement > > is > > "close-enough", but you have to stand on your head to recognize that the > > the > > boundary crossing can be close. > > > > I'll have to think hard about the boundary case. I think the subtract > > overflows but it gets the right answer. > > Modulo arithmetic saves your bacon. In fact that is why the type has to > be unsigned from the C standard point of view. > > The only remaining ambiguity is about the initial time of the system, > but as long as the assumption that it is never more than about 70 years > off the true time holds, you never need to care about the NTP era > explicitly… unless you're still dealing with a 32bit time_t, but the > strategy apparently was that by the time this becomes an issue > everything would have migrated to at least 64bit time_t. If not, you > could still bound the solution by assuming that ntpd cannot be running > before it has been compiled.
This whole area is badly documented, and that's a problem. When someone with Hal's domain expertise nevertheless doesn't fully grok it, and someone with my ability to see around corners in design space is still confused after being intimate with the code for years - that's a *real* problem. Would one of you please take the initiative to write up an outside-view description of how timestamp resolution works and add it to devel/tour.txt? Then the other of you (and I) can review it, all three of us can work together to dispel any remaining murk, and we'll have a solid basis to work from when we need to change relevant code. I feel this is necessary lest we break things. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel