From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 75f91efb for ; Fri, 24 Jan 2020 16:29:26 +0000 (UTC) Received: (qmail 9783 invoked by uid 550); 24 Jan 2020 16:29:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9762 invoked from network); 24 Jan 2020 16:29:24 -0000 Date: Fri, 24 Jan 2020 11:29:10 -0500 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200124162910.GX30412@brightrain.aerifal.cx> References: <20200119121247.37310-1-info@bnoordhuis.nl> <20200124140027.GT30412@brightrain.aerifal.cx> <878slw3mdo.fsf@oldenburg2.str.redhat.com> <20200124155458.GW30412@brightrain.aerifal.cx> <87k15g25q4.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k15g25q4.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [PATCH] add statx On Fri, Jan 24, 2020 at 05:12:51PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Fri, Jan 24, 2020 at 04:27:47PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > This is under BSD||GNU (i.e. DEFAULT||ALL) rather than just under the > >> > latter. Is there a reason for that? Generally the extensions that are > >> > pretty clearly Linux-only, as opposed to something that other > >> > POSIX-based OS's are likely to adopt, are put under GNU/ALL to > >> > discourage their use without intent and to avoid namespace clutter. > >> > >> statx is not Linux-specific in glibc, but also available on Hurd. > > > > OK, well GNU/Linux-specific. :-) Some ppl find _GNU_SOURCE odd for > > stuff that comes from Linux not GNU, but in this case it seems pretty > > appropriate since GNU and Linux are the two systems doing it. > > Sorry for nit-picking, it's common to both GNU and Linux. Yes, I was just making a bad joke about "GNU/Linux", reusing it to mean "applies to both GNU and to Linux". Sorry for being unclear. > >> We received feedback that our headers are not useful due to the > >> __u64/uint64_t mismatch. > >> > >> >> > > > > Uhg. That change seems unfortunate since it's incompatible with > > theoretical future archs having 128-bit long long -- an idea I'm not > > much a fan of, but don't actually want to preclude. Is there a reason > > to actually care about compatibility with the kernel types? > > Yes, printf format strings. 8-( Why not let ppl get the warnings and fix them by casting to an appropriate type to print. I prefer [u]intmax_t anyway to avoid the PRIu64 etc. mess that makes your format strings unreadable and that interferes with translation (*). > > It's not like both struct definitions can be included in the same > > source anyway; the tags would clash. Using the canonical uintN_t types > > makes more sense from an API perspective, I think; kernel assumptions > > about types should not leak into an API intended to be clean and > > shared with non-Linux implementations. > > I thought so too, which is why I used them. > > But it is fairly compelling to use the kernel types if the header is > available, so that we don't have to patch and rebuild glibc if someone > backports new statx features into the kernel. That's why I added the > __has_include kludge. I see. This is something of a tradeoff I guess; for musl users I'd expect folks to have libc headers newer than kernel headers in most cases since distros are slow to follow new kernels but fast to follow new libc, and you want compile-time support for future kernel features even if you don't have the kernel to use them yet. But on glibc-based dists it may be the other way around. Rich (*) GNU gettext has "SYSDEP" format strings that solve this problem but do so by requiring non-shareable string memory for all the affected strings. musl gettext does not support this, but is intended to be used with gettext-tiny's version of msgfmt that works out the combinatorics at .mo generation time and emits them all in shareable form. Still I think it's better to get rid of this practice and just use %jd etc. everywhere with suitable casts.