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
