der Mouse wrote:
>>> Knowing what "the maximally aligned type" *is* is machine- and/or
>>> compiler-dependent.
>> Except that CMSG_* will not be returning a double or float.
> 
> You don't know that.  I don't know that.  At present it won't, because
> none of the current interfaces do, but there's no way to promise that
> for all time.

Actually, I do.  If you look at the networking API, there is not floating
point types used because not all platforms support FP.  And NetBSD doesn't
not support FP in the kernel.  The socket API will only intergral types.

>> And it really isn't compiler dependent since C mandates that
>> alignment for char <= short <= int <= long <= long long.  So using
>> long long wouldn't be machine or compiler-dependent.
> 
> But it is, because there could be other types requiring even stricter
> alignment.  (Nothing promises that, for example, long long alignment is
> sufficient for pointers.)

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.

>> What I am saying CMSG_* is sufficient if you specify an aligned
>> buffer
> 
> Sufficient?  Perhaps.  But unclean and ugly.  I really dislike actually
> encouraging pointer punning (by not providing an interface that permits
> doing it correctly any other way).
> 
>> and the mechanism for that is not onerous.
> 
> That's a matter of opinion, and we obviously disagree on it.  But if
> the interface stands, it *really* needs to explicitly call out that the
> buffer needs to be aligned; that is not documented anywhere at present
> as far as I can see, unless you happen to be C wizard enough to infer
> it from the documented interfaces.

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

>> I think you are making a mountain out of molehill.
> 
> Perhaps.  I saw an ugly interface and proposed cleaning it up.  If you
> disagree about the aesthetics, or disagree about the importance of the
> aesthetics, well, then, perhaps I am.

You are.

> I just know that in my experience, the cleaner the code is, the easier
> it is to keep a lid on its bugs.  This includes extremely strict
> type-correctness in many respects, such as const poisoning,
> -Wmissing-prototypes -Wstrict-prototypes...and copying control message
> headers out of the buffer into struct cmsghdr objects rather than
> overlaying the objects onto the buffer.  Getting the alignment right
> without making fragile assumptions is just asking for too much trouble.

The requirement for alignment is no different than for getsockopt/setsockopt.
Also note that RFC2292 came out a year before C99.  It would have been hard
to reference C99'isms before they existed.

In case you haven't figured it out yet, I was the primary author of RFC2292.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.