From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 56B7F21765 for ; Mon, 27 Jan 2025 16:25:48 +0100 (CET) Received: (qmail 14073 invoked by uid 550); 27 Jan 2025 15:25:44 -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 x-ms-reactions: disallow Received: (qmail 14052 invoked from network); 27 Jan 2025 15:25:43 -0000 Date: Mon, 27 Jan 2025 10:25:34 -0500 From: Rich Felker To: enh Cc: musl@lists.openwall.com, Aditya Kumar Message-ID: <20250127152534.GR10433@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] fts.h On Thu, Jan 23, 2025 at 01:54:41PM -0500, enh wrote: > https://wiki.musl-libc.org/faq says "If glibc bug 15838 is fixed by > adding an fts64 interface in glibc, we could consider supporting it > with a matching ABI in musl, but it seems more likely that glibc will > just deprecate this interface", but that bug _was_ fixed in 2015 for > glibc 2.23... I wonder when that text was written. While we could certainly consider it, lack of any apparent need so far suggests that it wouldn't meet the modern criteria for inclusion in musl. The main motivation I could potentially see flipping this is if there are a significant number of programs shipping their own (e.g. gnulib?) versions of fts, that would save significant code-duplication disk space (or get better behavior of some sort) if using a shared copy in libc. Rich