Yo Hal! On Fri, 10 Mar 2017 17:00:21 -0800 Hal Murray <hmur...@megapathdsl.net> wrote:
> > Yes, but the overhead of timespec arithmetic is small, and pretty > > soon I don';t think we will do any arithmetic in l_fp. > > That seems strange. l_fp seems like an obvious choice to me. Sure, if the raw data is already in l_fp, but it is usually a timespec. > Please be very careful before undoing the current stuff. As I said yesterday, I gave up on the top dopwn approach. I have gone to bottom up. Fixing small things. It will prolly take me a week to deal with all the really obvious -Wsign-conversion warnings. I am trying to make all my commits very bytesize, so each is trivial to vet. Feel free to keep an eye on me. :-) > You can find all the places that do arithmetic by changing l_fp to a > record containing only one slot and fixing up the macros to do the > right thing. Then the compiler will tell you where you need macros > for add, sub, and compare. Except when all the nested casts confuse the compiler, and the programmer. > There are two parts to having good types. One is so it's easy to > write code and the compiler will do the right thing. The other is so > that it's easy to figure out what is going on when reading the code. Yup, and this particular type is real important to get right. Once I fix the casts we can start to see what is really happening. > My current problem is that there is no type for > ntp-seconds-since-epoch so we get things like "uint32_t now". I > suppose I could assume that all date/times that don't use time_t are > using NTP epoch but it would make me much happier of the source code > said so explicitly. Every time I figure out a type I am adding a comment. This is how I am finding a lot of pointless roundtripping between variable types. > > I am also baffled. The RFC defines NTP Date Format, but then never > > uses it anywhere.... > > That confirms that it isn't used on the wire. I think the idea is to > use it as a reference to show what the shorter version is trying to > represent. Gack. I hate unused code and I hate unused doc. > g...@rellim.com said: > > When gpsd ws compiled to assume all dates before compile date, then > > all the gpsd regressions, which are captures of earlier GPS output > > failed. > > Oops. :) Seems obvious now that you point it out. > > Does NTP have any regression test with dates stored in test-data > files? You'll have to ask Eric, I have not looked at the tests yet. I do see that the tests are worse than ntpd for bad casts. > I can think of a couple of solutions. The simple one is to use a > constant in some header file rather than the build date. Which is Why I suggested 2,208,988,800 (1 Jan 1970). > I like your suggestion of starting with 1970. There is an unstated > assumption that we will have to revisit that area sometime in the > future. But it's quite a ways in the future. 70 years after 2036 I'll unlikely care. > You could use the oldest date in your test cases. I like the symetry of 1970 as the beginning of POSIX Epoch and midway into NTP Epoch 0. > You could bump it occasionally, say at every release. Then you have to redo your regressions every release. A non-starter. 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
pgpekYnX28CqN.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel