lfpinit() signed or unsigned?

[Gary E. Miller]

Yo Hal!

On Fri, 10 Mar 2017 12:40:11 -0800
Hal Murray <hmurray at megapathdsl.net> wrote:

> gem at rellim.com said:
> >> Be careful with making negative values.  The case I'm worried about
> >> is dropping the carry out of the low half.  
> > The code has a normalize_tspec() ir prolly needs a
> > normalize_lp().   
> 
> There is nothing to normalize in a l_fp  All bit patterns are valid.

Sort of.  The header notes imply the integral and fractional part may be
signed or unsigned.  Separately.  I have not confirmed if the code use
that.


> > Because a RasPi has no RTC.  When it starts up it is always 1970
> > again. When 2036 comes, how will the RasPi know it is 2036 and not
> > 1970?   
> 
> I think the build date of the code will be a good start.

Which breaks regression tests.  We tried that on gpsd and the
results were, to be kind, loud.

Actually, there may be a better way.  NTP defines an Epoch on the 
wire.  I do not know when it is sent.  We are currently in NTP Epoch 0.
In 2036 it goes to NTP Epoch 1.  If we can grab that field off
the wire we are good.

Semms I believed someone that misread the RFC.  NTP Time is based on
1Jan1990, but when using the Epoch it can uniquely define any time
backwards or forward.

I just updated the comment in includes/ntp_fp.h.


> >> ctl_putfs is only used to printout leap second dates.  
> >Looks to me like it is creating an NTP mode 6 message in wire
> >format.  
> 
> The text on the wire is a date string:
>         snprintf(cp, sizeof(buffer) - (cp - buffer),
>                  "%04d%02d%02d%02d%02d", tm->tm_year + 1900,
>                  tm->tm_mon + 1, tm->tm_mday, tm->tm_hour,
> tm->tm_min);

Yeah, I went back to the file after getting it wrong.  I noticed that
code was obfuscated and tweaked it.  The conversion is from NTP Epoch to
POSIX Epoch.  A good place to use the existing conversion macro.

> 
> The values getting printed are coming from the leap-second file.
> #       The NTP timestamps are in units of seconds since the NTP
> epoch, #       which is 1 January 1900, 00:00:00.
> They are strings, so we don't have to worry about overflow.  We can
> convert to POSIX time_t when they are read in with a simple sub.

Good catch, another obfuscating use of l_fp!

> [My offer to try to fix that area]

Sounds like you have a way better handle than I do.  I'm off to
find other obfuscation.

If is is not obvious, many thanks for helping in this thicket!  I can
get lost in the twisty maze of passages, all seemingly alike...

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/f08a08bc/attachment.bin>