lfpinit() signed or unsigned?

[Gary E. Miller]

Yo Hal!

On Thu, 09 Mar 2017 19:46:46 -0800
Hal Murray <hmurray at megapathdsl.net> wrote:

> gem at rellim.com said:
> > Yeah, I see that now.  But as you pointed out, NTP time is already
> > modulo, so it only fails immediately after the rollover.  
> 
> > But that rollover is gonna be rough...   
> 
> I think it should be clean if/after we get the code right.
> 
> Assume we have 64 bit Unix/POSIX time_t.  The only interesting case
> is converting NTP time to Unix time.  That should work the same way
> that GPS week rollover does.  You need to figure out via some
> out-of-band source what the time is within 68 years.  The build time
> of of ntpd is one source.  The file system is another, but that can
> go crazy if you somehow get the time set way in the future.  The
> operator is another option.  Maybe ntpv5 will provide a way.  Maybe
> one of the sec options.

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

See RFC 5905, Figure 3: NTP Time Formats

https://www.ietf.org/rfc/rfc5905.txt

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

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.

Ah, another extern I can change to static...

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/20170309/51300a89/attachment.bin>