Diego Nieto Cid, le mar. 31 déc. 2024 02:47:35 +0000, a ecrit: > On Tue, Dec 31, 2024 at 02:02:53AM +0000, Diego Nieto Cid wrote: > > > > Here are the results for `hurd-amd64`: > > > > $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \ > > -pthread cred_size.c -lgio-2.0 -lgobject-2.0 -lglib-2.0 \ > > -o cred_size > > > > $ ./cred_size > > sizeof (int): 4 > > sizeof(struct cmsgcred): 84 > > CMSG_LEN(sizeof (int)): 20 > > CMSG_LEN(g_socket_control_message_get_size (scm)): 100 > > > > and here the results for `hurd-i386`: > > > > $ ./cred_size > > sizeof (int): 4 > > sizeof(struct cmsgcred): 84 > > CMSG_LEN(sizeof (int)): 16 > > CMSG_LEN(g_socket_control_message_get_size (scm)): 96 > > > > I think the usage of size_t is what breaks the computation on > hurd-amd64 (8 bytes while on i386 is 4): > > #define CMSG_ALIGN(len) (((len) + sizeof (size_t) - 1) \ > & (size_t) ~(sizeof (size_t) - 1))
That's how it is defined in Linux too. CMSG_ALIGN really needs to be aligned so. > #define CMSG_SPACE(len) (CMSG_ALIGN (len) \ > + CMSG_ALIGN (sizeof (struct cmsghdr))) > #define CMSG_LEN(len) (CMSG_ALIGN (sizeof (struct cmsghdr)) + (len)) This alignment is also required. > I'm not sure how to fix it. Should the expectations of GLib be updated > to be aligned? Like below: > > - if (size != G_CREDENTIALS_NATIVE_SIZE) > + if (size != CMSG_ALIGN(G_CREDENTIALS_NATIVE_SIZE)) > > Or should the macros be updated to use a 4 bytes size_t equivalent? I'd rather say it's our socket layer which is aligning cmsg_len while it shouldn't, since it's CMSG_NXTHDR that aligns it to get to the next header. Samuel