Date: Tue, 12 Nov 2019 21:46:20 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Cc: Rich Felker <dalias@...ifal.cx> Subject: Re: [RFC] fanotify_event_info_fid incompatibility * Petr Vorel <petr.vorel@...il.com> [2019-11-12 21:05:20 +0100]: > musl defines struct fanotify_event_info_fid member fsid as fsid_t. This > conflicts with version from Linux kernel, which defines it as __kernel_fsid_t > (musl's fsid_t has int __val, kernel's __kernel_fsid_t has int val). > > I see commit 32b82cf5 ("fix the fsid_t structure to match name of __val"), > which looks correct to me. > > I also think it's wrong, that other libc (at least glibc, uclibc-ng, bionic) > don't define fanotify_event_info_fid and other structs thus users are forced to > use definition from <linux/fanotify.h>. But can be something done with this > incompatibility? yeah, glibc sys/fanotify.h just includes linux/fanotify.h which uses linux types instead of libc ones, this is a common pattern and there is no clean solution if users rely on that in such cases i try to keep updating sys/foo.h following linux/foo.h changes, but in musl i try to use libc types (e.g. if a field is __u64 then passing a pointer to it as uint64_t* may not be valid so the glibc way is quite problematic) glibc fsid_t uses __val but the __kernel_fsid_t has val, musl could use a different type instead of fsid_t for fanotify that has __val, but it's a bit ugly, is there a reason to access fsid_t.val?
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.