From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12948 invoked from network); 3 Sep 2021 13:12:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Sep 2021 13:12:29 -0000 Received: (qmail 11781 invoked by uid 550); 3 Sep 2021 13:12:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11763 invoked from network); 3 Sep 2021 13:12:26 -0000 Date: Fri, 3 Sep 2021 09:12:13 -0400 From: Rich Felker To: "J. Hanne" Cc: musl@lists.openwall.com Message-ID: <20210903131212.GE13220@brightrain.aerifal.cx> References: <20210903101352.379FC2FC06B2@dd11108.kasserver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210903101352.379FC2FC06B2@dd11108.kasserver.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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