[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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[2], kernel's __kernel_fsid_t has int val[2]).
>
> 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.
