On Mon, Nov 28, 2022 at 07:30:36PM +0100, Steffen Nurpmeso via austin-group-l at The Open Group wrote: > Austin Group Bug Tracker wrote in > <aac7202c6ad40688aa8633c3f9d38...@austingroupbugs.net>: > ... > |https://austingroupbugs.net/view.php?id=561 > ... > |---------------------------------------------------------------------- > | (0006085) geoffclare (manager) - 2022-11-28 16:24 > | https://austingroupbugs.net/view.php?id=561#c6085 > |---------------------------------------------------------------------- > ... > |<blockquote><tt>char sun_path[<i>size</i>]</tt> Socket pathname > |storage. > ... > |[.] However, because <i>sun_path</i> is required to be the > |last member of the struct, an application can deduce the size by using > |<tt>sizeof(struct sockaddr_un) - offsetof(struct sockaddr_un, > |sun_path)</tt>.</blockquote> > > I am glued to old habits, but given it is the last field and of > a known fixed size sizeof(NAME.sun_path) should be all that is > necessary. (It definitely is in practice.) > (And all this different to SUN_LEN(), of course.)
Two comments in response: First, I chose that wording because 'sizeof(struct sockaddr_un.sun_path)' doesn't compile. You are right that 'sizeof NAME.sun_path' does compile, if NAME is an expression of type struct sockaddr_un, but the sentence becomes longer to introduce some object named NAME of the correct type just to get to the shorter sizeof expression. However, we can make that edit if it makes sense. Second, given alignment issues, a choice of an odd size coupled with other members that require even alignment could permit an implementation where sizeof(struct sockaddr_un) > offsetof(struct sockaddr_un, sun_path) + sizeof(NAME.sun_path) due to padding bytes added for alignment reasons. I don't know of any such implementations in practice (the choice of 92, 104, and 108 as the most common sizes tends to be so that the overall struct sockaddr_un has a size of 128 bytes, which is a nice power-of-two boundary). Then again, intentionally forcing struct sockaddr_un to have a padding byte after sun_path might be an implementation's way of guaranteeing that it can handle a NUL byte even if the application didn't pass one in. Therefore, do we need to modify the wording in this proposal to ensure that struct sockaddr_un is not allowed to have padding bytes after sun_path to match existing practice? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
