>> ([This] would also eliminate the need for
>> __cmsg_alignbytes, which is rather an aesthetic blemish.)
> this is to address concern on 32bit/64bit dual archs.
> for instance, kernel is running in 64bits, alignment would be 8
> bytes.  if we hardcode CMSG_ALIGN to be 4 (for 32bit mode) userland
> and kernel will fail to communicate.

Yes - or 32-bit SPARC, which had 8-byte usermode alignment but 4-byte
CMSG_ALIGN alignment before that went in (this is what prompted me to
notice it; I had a program coredump as a result of this mismatch).

But my question was not "why is __cmsg_alignbytes there today", but
rather,

>> Why not, instead, have the kernel increase the cmsg_len values to
>> whatever boundary it thinks appropriate?

So that, for example, a cmsg_len that's natively 20 would be increased
to 24 by the kernel (probably in recvit()'s loop), so that cmsg_len is
_always_ the right amount for userland to advance its pointer by?

/~\ 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