lfpinit() signed or unsigned?

[Gary E. Miller]

Yo Hal!

On Fri, 10 Mar 2017 17:00:21 -0800
Hal Murray <hmurray at 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.

> gem at 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
	gem at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170310/630a8a2b/attachment.bin>