lfpinit() signed or unsigned?

[Hal Murray]

> 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.

Please be very careful before undoing the current stuff.

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.

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.

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.



> 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.


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?

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.

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.

You could use the oldest date in your test cases.

You could bump it occasionally, say at every release.  That will break 
some/many tests.  You would have to fix those, but only when you bump it.  
The idea is to bump it often enough so that you remember to do it but not so 
often that the fixup step takes too much time.

You could make a command line option to set the pivot point so the test 
harness could set it back.



-- 
These are my opinions.  I hate spam.