lfpinit() signed or unsigned?

[Hal Murray]

gem at rellim.com said:
>> How about something like l_fp_time (unsigned) and
>> l_fp_delta or l_fp_offset (signed)?
> I'm now leaning that way too.  And two ways to make an l_fp, one starting
> with int's and the other uint's. 

Be careful with making negative values.  The case I'm worried about is 
dropping the carry out of the low half.


> The npd code is gonna be OK, the problem is that the NTP wire protocol for
> timestamps is in 32 bits! 

Why is that a problem?  If you work with 64 bits of seconds, just drop the 
top half.  If you work with 32 bits of seconds, you will get the same answer. 
 Parts may get dropped along the way when stuff overflows.

To convert between NTP and Unix...  Until 2036, you just add/sub JAN_1970.  
After 2036 add/sub JAN_1970 and 1<<32 if T < build date.  (Or something close 
to that.)

gem at rellim.com said:
>> Does the current code have the right variable?  Have you found it?
>> Is there more than one place that does NTP to Unix conversion?
> Sort of.  The conversion constant is JAN_1970.  That is defined in include/
> ntp_calendar.h.

That constant doesn't have anything to do with calendars.  I'm not sure where 
it should go.

In the long run, it's more complicated.  See above.

> There is a macro to do the conversion from timestamp to NTP Epoch:
> tspec_stamp_to_lfp(), but it is not always used.

> There look to be just two places the conversion from NTP Epoch is done:
> ntpcal_ntp_to_time() and ctl_putfs().  And the later not even using l_fp,
> it uniquely uses tstamp_t which is seconds based on NTP Epoch.

ctl_putfs is only used to printout leap second dates. I don't see any reason 
to involve NTP date formats or epochs.  From a quick glance, the NTP in the 
comment where it is defined looks bogus.  I'll clean that up if you want to 
unload a nice small chunk, but it looks like you have already done something 
in that area.

I haven't sorted out ntpcal_ntp_to_time yet.






-- 
These are my opinions.  I hate spam.