> Then use intmax_t instead.  intmax_t is defined as holding the
> largest integral value and will be able to contain a pointer as well.

Will be able to contain a pointer, sure.  But not necessarily, will be
at least as strictly aligned as a pointer.

> Neither is it stated that getsockopt needs an aligned buffer, but one
> seems to screw that up either.

("but no one seems...", I assume.)

This, I think, is (a) because getsockopt *doesn't* need an aligned
buffer, any more than sendmsg and recvmsg do, and (b) because
getsockopt's buffer usually has no more structure than a single object
of a specific type (an int for most options, a struct for a few of
them), for which passing a pointer to the object itself is suitable.
If there were an option whose getsockopt buffer had structure
complicated enough to find something akin to CMSG_* useful, and that
something exhibited the kind of problems I see with CMSG_*, I would
argue for its improvement too.

> The requirement for alignment is no different than for
> getsockopt/setsockopt.

Disagree; see above.  There is no alignment requirement for sendmsg or
recvmsg; the alignment requirement arises only because there is no
(documented/supported) way to pick apart the control data buffer if
it's misaligned, without depending on things like pointers outside of
objects.  (Which latter is what I generally do; that seems less ugly to
me than the contrivances necessary to ensure the buffer is properly
aligned.)

> Also note that RFC2292 came out a year before C99.  It would have
> been hard to reference C99'isms before they existed.

None of the problems depend on either the presence or absence of
C99isms.  None of my suggested fixes depend on C99isms.  I don't see
that C99 has much of anything to do with the issue.

> In case you haven't figured it out yet, I was the primary author of
> RFC2292.

I don't see how that's relevant, unless you think that because you
wrote it it must be perfect or some such. :-)  It still has all the
weaknesses it did all along.  (And strengths, to be sure, but this
discussion has been more about weaknesses.)

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