> On 05/14/2022 8:42 PM Hal Murray via devel wrote:
>
>
> I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the
> discussion real email..
>
>
> > include/ntp_fp.h:58 defines l_fp as a uint64_4, I can find no current
> > contrary definitions.
>
> We need to make a cleanup
> On 05/14/2022 8:53 PM Gary E. Miller via devel wrote:
>
>
> Yo Hal!
>
> On Sat, 14 May 2022 17:42:59 -0700
> Hal Murray via devel wrote:
>
> > I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the
> > discussion real email..
> >
> >
> > > include/ntp_fp.h:58 defines l_fp
> On 05/14/2022 9:42 PM Hal Murray via devel wrote:
>
>
> > Not yet in the delvel emailarchives: What distro is broken by this?
>
> I've only seen it on FreeBSD. It's in the development branch and will be in
> 13.1 which will be released in a few days.
>
> It's in clang. Unless FreeBSD
> Not yet in the delvel emailarchives: What distro is broken by this?
I've only seen it on FreeBSD. It's in the development branch and will be in
13.1 which will be released in a few days.
It's in clang. Unless FreeBSD has broken their copy, it will appear in other
distros as things get
Gary said:
> I'm OK with commenting it out, just the two lines, until we figure out what
> clang is doing. But I'd rather figure it out...
I agree that we should figure it out, but we should get the release out first.
--
These are my opinions. I hate spam.
Yo Hal!
On Sat, 14 May 2022 17:42:59 -0700
Hal Murray via devel wrote:
> I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the
> discussion real email..
Not yet in the delvel emailarchives: What distro is broken by this?
RGDS
GARY
Yo Hal!
On Sat, 14 May 2022 17:42:59 -0700
Hal Murray via devel wrote:
> I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the
> discussion real email..
>
>
> > include/ntp_fp.h:58 defines l_fp as a uint64_4, I can find no
> > current contrary definitions.
>
> We need to
I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the
discussion real email..
> include/ntp_fp.h:58 defines l_fp as a uint64_4, I can find no current
> contrary definitions.
We need to make a cleanup pass in this area.
On the wire, it's unsigned. As soon as the code gets 2 of