recvmsg() length report

[Fred Wright]

On Mon, 3 Feb 2025, Hal Murray via devel wrote:
>
> Linux:
>  x86-64:16
>      I don't have any really really old systems.
>  x86-32: 8
>    Debien, 6.1.0-29-686-pae i686
>  Arm:  8
>  Arm64: 16
>
> FreeBSD:
>  x86-64: 20  <===
>  x86-32: 8
>  Arm: 16
>  Arm64: 20  <===
>
> NetBSD:
>  x86-64: 20  <===
>  x86-32: 12
>  Arm: 20  <===
>    long is 4, time_t is 8, timespec is 16

For those not in the MR discussion, this is about the cmsg payload length 
from the packet-timestamp option, not the general message length.

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. :-)

Actually, I think I understand the 20-byte case as well.  It's adding yet 
another 4 bytes of padding so that the *overall cmsg length* is 64-bit 
aligned.  It's of course impossible for both the payload and the complete 
message to be 64-bit aligned at the same time, since the header length is 
an odd multiple of 32 bits.

What's the breakdown in the 32-bit NetBSD case?  One would hope that the 
payload is 64+32 and not vice versa.

Fred Wright