e...@thyrsus.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?
> What you're looking for is called the "pivot point", snd it's implemented in
> libntp/systime.c.
Thanks.
> There used to be sporadic N
e...@thyrsus.com said:
>> How about something like l_fp_time (unsigned) and
>> l_fp_delta or _fp_offset (signed)?
> More detail, please?
Replace
typedef uint64_t l_fp;
with
typedef uint64_t l_fp_time;
typedef int64_t l_fp_offset;
Then replace all the places that used to use l_fp with the
Hal Murray :
> >> What I was trying to suggest is that another layer of macros might
> >> eliminate a batch of casts.
> > Well, maybe. I didn't find a way to do that. It's possible I wasn't clever
> > enough.
>
> How about something like l_fp_time (unsigned) and l_fp_delta or l_fp_offset
> (sig
Hal Murray :
>
> g...@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 h
Yo Hal!
On Thu, 09 Mar 2017 20:02:46 -0800
Hal Murray wrote:
> That makes sense. Unsigned on the wire. Signed internally for
> deltas.
Seems so.
> 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
Yo Hal!
On Thu, 09 Mar 2017 19:46:46 -0800
Hal Murray wrote:
> g...@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 cl
e...@thyrsus.com said:
>> Do any of the casts actually change any bits?
> I believe not.
Then all the casts are just noise to keep the compiler happy and/or hints to
tell the reader what the intent is.
> I believe the RFC intention is that they should be unsigned offsets from an
> epoch date,
g...@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. Th
Yo Hal!
On Thu, 09 Mar 2017 18:39:13 -0800
Hal Murray wrote:
> > Everything still fits. At least until 2038. 7FFFu is
> > 2147483647 which as a time_t is "Mon Jan 18 19:14:07 PST 2038".
>
> There are two issues.
> Unix time stamps overflow 31 bits in 2038.
> NTP time stamps overflow
g...@rellim.com said:
> So we are now doing modulo arithmetic.
I believe that ntpd expects to be using modular arithmetic for time.
I don't have a handy pointer to any documentation to back that up.
Most of the internal calculations are done with time represented as the
offset from the system
Yo Eric!
On Thu, 9 Mar 2017 17:11:54 -0500
"Eric S. Raymond" wrote:
> > > Too often the unsigned type is then used to compute offsets and
> > > the casts get ugly.
> >
> > Gack... I gotta do a quick U-turn on this. I found some pretty
> > hidden assumptions that I did not expect in the code
Gary E. Miller :
> Yo Eric!
>
> > > > Would it help to have another signed type?
> > >
> > > The short answer is "no". The longer answer:
> >
> > I'm starting to disagree, I see a need for only a signed type.
> >
> > Too often the unsigned type is then used to compute offsets and the
> >
Yo Hal!
On Thu, 09 Mar 2017 13:11:36 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > From what I can tell, until 2038, l_fp never uses the top bit,
> > except to do sidewise fake at goping negative. I see no reason
> > l_fp can not be signed. We'll know soon
>
> Interesting. I tho
Yo Eric!
> > > Would it help to have another signed type?
> >
> > The short answer is "no". The longer answer:
>
> I'm starting to disagree, I see a need for only a signed type.
>
> Too often the unsigned type is then used to compute offsets and the
> casts get ugly.
Gack... I gotta do
Hal Murray :
> Do any of the casts actually change any bits?
I believe not.
> What I was trying to suggest is that another layer of macros might eliminate
> a batch of casts.
Well, maybe. I didn't find a way to do that. It's possible I wasn't clever
enough.
> Do any of the RFCs discuss the si
Gary E. Miller :
> And since it is one patch, you can revert it if need be.
>
> If you want, I can post a git diff for review first.
I'd like to see that.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon page at https://www.patreon.com/es
e...@thyrsus.com said:
> The macros that are the API for the abstract data type are constructed to be
> indifferent to whether the underlying concrete 64-bit type is signed or
> unsigned. If I were willing to commit either way I could throw away several
> of them in favor of bare arithmetic opera
Yo Eric!
On Thu, 9 Mar 2017 15:42:20 -0500
"Eric S. Raymond" wrote:
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > It doesn't matter. All those calculations are casted to within
> > > an inch of their lives. :-)
> >
> > Would it help to have another signed type?
>
> The short ans
Hal Murray :
>
> e...@thyrsus.com said:
> > It doesn't matter. All those calculations are casted to within an inch of
> > their lives. :-)
>
> Would it help to have another signed type?
The short answer is "no". The longer answer:
The macros that are the API for the abstract data type are co
Yo Hal!
On Thu, 09 Mar 2017 12:16:38 -0800
Hal Murray wrote:
> e...@thyrsus.com said:
> > It doesn't matter. All those calculations are casted to within an
> > inch of their lives. :-)
>
> Would it help to have another signed type?
From what I can tell, until 2038, l_fp never uses the top
Gary E. Miller :
> > Yes, they do. I inherited that logic.
>
> Then you're not offended when I change it.
Well, not in the sense of being attached to it. I'm just nervous
about anyone changing it, even someone as good as you. I feel like it
would be too easy to violate some assumption neither
e...@thyrsus.com said:
> It doesn't matter. All those calculations are casted to within an inch of
> their lives. :-)
Would it help to have another signed type?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http
Yo Eric!
On Thu, 9 Mar 2017 14:35:20 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > It gets worse. Looks like l_fp needs to be int64_t, not uint64_t.
> > Sometimes l_fp's are subtracted to get an offset.
>
> It doesn't matter. All those calculations are casted to within an
> inch of
Gary E. Miller :
> It gets worse. Looks like l_fp needs to be int64_t, not uint64_t.
> Sometimes l_fp's are subtracted to get an offset.
It doesn't matter. All those calculations are casted to within an inch of
their lives. :-)
> And weird things happen in lfp_intv_to_tspec() to guess if l_fp i
Yo Hal!
On Wed, 08 Mar 2017 20:38:33 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > Does lfpinit() need to return a signed? Or should the parameters to
> > lfpinit() annd be unsigned? I'm guessing the later, but I'm new to
> > that part of the code...
>
> I think both parameters shoul
25 matches
Mail list logo
