From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14932 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC] fanotify_event_info_fid incompatibility Date: Tue, 12 Nov 2019 21:46:20 +0100 Message-ID: <20191112204619.GI25646@port70.net> References: <20191112200520.GA13138@x230> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="46381"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Rich Felker To: musl@lists.openwall.com Original-X-From: musl-return-14948-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 12 21:46:35 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iUd3b-000ByB-At for gllmg-musl@m.gmane.org; Tue, 12 Nov 2019 21:46:35 +0100 Original-Received: (qmail 3694 invoked by uid 550); 12 Nov 2019 20:46:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3670 invoked from network); 12 Nov 2019 20:46:32 -0000 Mail-Followup-To: musl@lists.openwall.com, Rich Felker Content-Disposition: inline In-Reply-To: <20191112200520.GA13138@x230> Xref: news.gmane.org gmane.linux.lib.musl.general:14932 Archived-At: * 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 . 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?