Specifically, RFC3542 says that msg_controllen may include padding
  after the last control message (which in our implementation means
  padding to the boundary determined by __cmsg_alignbytes()).  But if I
  do this, the test in unp_internalize() that tests for
  cm->cmsg_len != control->m_len fires, because cm->cmsg_len is the
  CMSG_LEN() value whereas control->m_len is the CMSG_SPACE() value.

  Am I smoking crack, or is this a real bug?  It looks to me as though
  the test in unp_internalize should read cm->cmsg_len > control->m_len
  to allow for padding.

It looks like a real bug, if the RFC allows padding at the end (as
opposed to between).  The test should be >=, though, and this begs the
question whether it is allowable to have a second cmsghdr with
something else on the send call, rather than just extra padding
(guessing 4 bytes of padding on sparc or sparc64, where
__cmsg_alignbytes is 8, I think).


-- 
        Greg Troxel <gdt@ir.bbn.com>