Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Nov 2019 21:46:20 +0100
From: Szabolcs Nagy <>
Cc: Rich Felker <>
Subject: Re: [RFC] fanotify_event_info_fid incompatibility

* Petr Vorel <> [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

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.