recvmsg() length report

[Fred Wright]

On Tue, 4 Feb 2025, Hal Murray wrote:
>
>> As Alice would say, "curiouser and curiouser".  Just when I think I've
>> figured out the reason for one bit of bizarreness, you find another. :-)
>
> I think the current code works on all my systems.
>
>
>> What's the breakdown in the 32-bit NetBSD case?  One would hope that the
>> payload is 64+32 and not vice versa.
>
> #define NTP_SIZEOF_LONG 4 /* Size of long from <None> */
> #define NTP_SIZEOF_STRUCT_TIMESPEC 12 /* Size of struct timespec from
> <time.h> *
> /
> #define NTP_SIZEOF_STRUCT_TIMEVAL 12 /* Size of struct timeval from
> <sys/time.h>
> */
> #define NTP_SIZEOF_TIME_T 8 /* Size of time_t from <time.h> */
>
> [This is an example of why I want that sizeof stuff.]

By "breakdown" I meant the sizes actually seen by the compiler, not some 
separately derived macros.

I decided that it's best just to have an easily run standalone test for 
this issue, rather than relying on hacking ntpd itself.  I have a little 
more work to do on it, and will submit it as a separate MR (for the 
'attic') when I'm done.

One thing I've found already is that those apparent 20-byte payloads are 
bogus.  What's actually happening in those cases is that the *header* is 
getting padded to a 64-bit boundary.  This is reflected in the behavior of 
CMSG_DATA, but not in sizeof(struct cmsghdr).

After I finish the test program, I'll revisit the actual fix, in light of 
new understanding.

Fred Wright