>> Now, would it really have been so difficult to answer "because
>> RFC2292 says so" to my first message?
> CMSG_ALIGN is not in RFC2292 (local to netbsd),

Well, yes, but that is a suitable retort to the "why not count the
padding in cmsg_len" suggestion.

> i assumed that you have seen the diagram before writing the first
> message (= knows meaening of cmsg_len and issues with padding).

No, I ran into it the hard way: the version I run at home doesn't have
__cmsg_alignbytes(), and on the SPARC it uses 8 in the kernel and 4 in
userland.  This means that if an ancillary data object has a cmsg_len
that rounds up to an odd multiple of 4, the kernel skips four bytes
that userland doesn't.  I had a program core because of this, and it
took debugging code and some hair-pulling before I put together the
ALIGN() in recvit()'s loop with the comment on CMSG_ALIGN and twigged
to what was going on.

Putting the padding in cmsg_len - or else adding another field, akin to
a directory entry's d_reclen - seems like a much cleaner design than to
depend on each side to know what padding the other side is expecting.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B