ntpsec | ntp_packetstamp: Fix possible time_t size mismatch. (!1414)

[Gary E. Miller]

Yo Fred!

On Tue, 24 Dec 2024 15:21:14 -0800 (PST)
Fred Wright via devel <devel at ntpsec.org> wrote:

> On Tue, 24 Dec 2024, Gary E. Miller (@garyedmundsmiller) wrote:
> > Gary E_ Miller
> > commented: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1414#note_2273464732
> >
> >
> > I don't know about OSX, but this is not the proper GNU libc fix.
> >
> > With GNU libc, the size of time_t on 32-bit ABI depends on two
> > #defines.
> >
> > '-D_FILE_OFFSET_BITS=64', '-D_TIME_BITS=64',
> >
> > This is the nut of issue #832.  No heuristics needed, just check
> > the two #define.  And they change a more than just time_t.  
> 
> You're missing the point.  If the format of the timestamp returned
> with the packet differs from the userspace format that the userspace
> code expects (regardless of what that userspace format is), the
> timestamp needs to be converted.

Sorry, I should have read closer, if you are just looking at the
on the wire NTP packet then my comments are not on point.  I though
the NTP packets were fixed by RFC?

I'll look at the RFC.

> Unless
> of course you're worried about its returning something entirely
> different than the expected timespec/timeval struct, in which case
> all bets are off, anyway.

The wire packet is eactly defined...

https://www.rfc-editor.org/rfc/rfc5905

What exactly is changing??

> The defines you mention determine userspace expectations.  If they're 
> guaranteed to match the supplied timestamp, then fine, no conversion. 
> That's definitely not true in at least some OSX cases.

I'm lost, how does OSX redefine the wire format?

> I don't know what issue #832 is,

I put the link in my comment.  Still there.  Here it is again:

https://gitlab.com/NTPsec/ntpsec/-/issues/832

> but I don't see any "issues" link on
> the project's GitLab page, making it hard to look up.

Start at this MR:

https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1414

Top right is an icon that maybe looks a kindergarden drawing of a book??
Click that.  It opens the sidebar, then  issues is in that near the top.

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