[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210903131212.GE13220@brightrain.aerifal.cx>
Date: Fri, 3 Sep 2021 09:12:13 -0400
From: Rich Felker <dalias@...c.org>
To: "J. Hanne" <musl@...hanne.name>
Cc: musl@...ts.openwall.com
Subject: Re: CMSG_LEN macro
On Fri, Sep 03, 2021 at 12:13:52PM +0200, J. Hanne wrote:
> Hi,
>
> can somebody enlighten me on the purpose of "CMSG_ALIGN (sizeof
> (struct cmsghdr))" in
>
> #define CMSG_LEN(len) (CMSG_ALIGN (sizeof (struct cmsghdr)) + (len))
>
> of https://git.musl-libc.org/cgit/musl/tree/include/sys/socket.h?
>
> CMSG_ALIGN seems to round up to a multiple of sizeof(size_t) - e.g.
> to a multiple of 4 on x86/arm and to a multiple of 8 on
> x86_64/aarch64?
>
> Given struct cmsghdr, which has a size of 16 bytes on all 4
> mentioned archs, I already wonder if this has an effect on any
> real-world architecture.
I believe you're correct that it's not actually needed to define
CMSG_LEN, and in some sense "couldn't be needed". It is documented
(very sparsely) by the Linux man page for cmsg, and so the purpose of
having it available to applications is just meeing that part of the
(extended) API. It would be interesting to look at what (potentially
wrong) things applications are using it for.
> But more importantly, I wonder *what* exactly is supposed to being
> aligned here:
>
> - Shall it put some padding *before* struct cmsghdr? That doesn't
> seem to make sense as the result of CMSG_LEN() goes into the
> cmsg_len member of struct cmsg, so it would seem strange to me to
> include bytes preceding the struct in its length field.
> - Shall it put some padding *after* struct cmsghdr? In this case,
> CMSG_DATA would be wrong as it puts the data directly behind
> struct cmsghdr without any padding between.
Conceptually any padding needed for alignment is after the cmsghdr. If
the padding were nonzero length then our definition of CMSG_DATA would
be wrong. But the application can't know this; that's why it has to
use the CMSG_* macros.
I think it may make sense to remove all internal use of CMSG_ALIGN
since it's nonstandard and a no-op where it's being used now. Then it
could be left just for applications to use to align their data sizes
or whatever.
Anyone else have thoughts on this?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
