Subject: Re: ancillary data alignment and binary backward compatibility
To: Chris G. Demetriou <firstname.lastname@example.org>
From: None <email@example.com>
Date: 03/12/2000 14:49:42
>> >> #define CMSG_NXTHDR(mhdr, cmsg) \
>> >> ( ((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \
>> >> (((u_char *)(cmsg) + ALIGN((cmsg)->cmsg_len) \
>> >> + ALIGN(sizeof(struct cmsghdr)) > \
>> >> (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \
>> >> (struct cmsghdr *)NULL : \
>> >> (struct cmsghdr *)((u_char *)(cmsg) + ALIGN((cmsg)->cmsg_len))) )
>> >> The macro ALIGN(), which is implementation dependent, rounds its
>> >> argument up to the next even multiple of whatever alignment is
>> >> required (probably a multiple of 4 or 8 bytes).
>Obviously, they're talking about a general 'ALIGN' macro, which may or
>may not be the same as our specific alignment function. our specific
>Note that it says "next even multiple of whatever alignment is
>This is different than the alignment provided by our ALIGN macro and
>ALIGNBYTES value. They align to the maximum possible necessary
>alignment, not the actual alignment needed.
I'm very convinced that ALIGNBYTES is correct here. We can't foresee
what kind of structs are put into ancillary message. If we use
something smaller than ALIGNBYTES, every time we pass new struct via
ancillary message (which exceeds the alignment defined) we need to
change CMSG_ALIGN and we'll have binary compatibility issue.
So, at least need to bump from 3 to ALIGNBYTES.
- How to bump
- how to determine ALIGNBYTES (statically by header of hw.alignbytes
current tree uses hw.alignbytes
is still not 100% decided...