summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/parse_data_structs.py
diff options
context:
space:
mode:
authorMarcel W. Wysocki <maci.stgn@gmail.com>2026-02-15 22:28:02 +0800
committerJohannes Berg <johannes.berg@intel.com>2026-03-21 10:41:44 +0100
commit4076f7329832074196e050def49d22265fce2021 (patch)
tree3d2bf9bd1b0eec818fd3b20ef07768afa9855ed2 /tools/lib/python/kdoc/parse_data_structs.py
parentf338e77383789c0cae23ca3d48adcc5e9e137e3c (diff)
um: fix address-of CMSG_DATA() rvalue in stub
The UML stub takes the address of CMSG_DATA(fd_msg): fd_map = (void *)&CMSG_DATA(fd_msg); CMSG_DATA() is specified by POSIX to return unsigned char *. Taking its address is semantically wrong -- the intent is to get a pointer to the control message data, which is exactly what CMSG_DATA() already returns. This happens to compile with glibc because glibc's primary CMSG_DATA definition accesses a flexible array member: #define CMSG_DATA(cmsg) ((cmsg)->__cmsg_data) An array lvalue can have its address taken, and &array yields the same address as array. However, glibc also has an alternative definition that uses pointer arithmetic (returning an rvalue), and musl's definition always uses pointer arithmetic: /* musl */ #define CMSG_DATA(cmsg) \ ((unsigned char *)(((struct cmsghdr *)(cmsg)) + 1)) Taking the address of an rvalue is a hard error in C, so the current code fails to compile with musl libc. Remove the erroneous & operator. The resulting code is correct regardless of the CMSG_DATA implementation -- it simply assigns the data pointer, which is what the subsequent code (fd_map[--num_fds]) expects. No functional change with glibc; fixes the build with musl. Signed-off-by: Marcel W. Wysocki <maci.stgn@gmail.com> Link: https://patch.msgid.link/20260215142803.1455757-1-maci.stgn@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'tools/lib/python/kdoc/parse_data_structs.py')
0 files changed, 0 insertions, 0 deletions