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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 619FF21344 for ; Mon, 27 Jan 2025 16:35:09 +0100 (CET) Received: (qmail 9978 invoked by uid 550); 27 Jan 2025 15:35:05 -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 9949 invoked from network); 27 Jan 2025 15:35:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737992096; x=1738596896; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8iUBmUf/TZ8sXVazeGQdY9JzAs0PtvwAJbFIdiU22N4=; b=V77S30cEqJheeznXFaMmQ0CdsAIJisApFgEuWzh71iVtvOJfp1WrKMlKgqagTD6qdZ MErEBBuNHm58yUaHqHIxDwckkbVmo2pj1d/HJIEPhvMgkmO9fZOCVjM2jwjqJsc9GuBZ TkIHyaRwZiMMXWBjP6pZW0y6UseyM+/LP0teWWaHCWzbxqMEtkRs/Umo/Bgp6FFl6MaD QUiNnuY/+MErJwZ0ifqeArIj0egujXPv5J7Nr5JqKC22EN6u/QMf6i3jZDAKT9wd+w3Q Wkui7wXIrRdvGMgDua1gVa5bpvDrKH7ZOP2kqmRx6tFo+/DCExxKoiWdg0xT1aML3sjZ bVlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737992096; x=1738596896; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8iUBmUf/TZ8sXVazeGQdY9JzAs0PtvwAJbFIdiU22N4=; b=Q49Pj1HNmDO4mTC485VbQ8bh+JSP+sNWt3zE14q58QauXRh1BigiChNbtPZcBe7b4f 9lOF2VtIK8Z19Wuubd0Qd+j4j4SF+1drzx6C0Omuew5dkhn3kmnXrERhUikj0xTGD6jm BKlmIlbrl66Tw4vzHsAHYtAaUYiLPSc84lzi31GUHWeQkusDbKbf01LOvAQpXBJCmg70 GDPc3Uv0LhQqjUB6hjaX5ixaU7P4DQJPvHAyjuBr4dqwShYyx0YKtMSNc1eLfrHWP5ew 719f8PBIyeL1POSiYEXjpx3C6h6UUgyKBTblhlsykny+2vs6UiMA2LKnb0uh5fqBUYOJ EKJw== X-Gm-Message-State: AOJu0YwULne+RJi9RatdG1beChDWMbN3e/Qu7dJfF65KQu2ehq4zdJpm Fp87EwOpk3KOexDYNk4IfB/rX9ubHYAB8R33VfsQ44vucLyEeLlGqeRAkCpZF3zO85zd+bpJQjo c0At72har1n8Yun5KFjLJhqMGpqnEAkJ5NKXn X-Gm-Gg: ASbGncv1cEZXN/0p2BHq2Q/A8sZD6lrJOF2T78BPtgTwL4HV+A9QX3NpOj6XxMrdWob 1GK9cwYBPLY9E0AIbTriF1Fu/ey7YTehm89px469Oy6f2MlunfoHQBWD6FYg= X-Google-Smtp-Source: AGHT+IHVVluUUJdPgg+nA6iGVj1iKRa3B4M+itemeYj+DVeUiuMw2q+MK2Kh+wRPGpxvvUg6RRnMauOOQO+Y4ctC9Vw= X-Received: by 2002:a05:6870:164a:b0:288:60d6:f183 with SMTP id 586e51a60fabf-2b1c103f515mr23696565fac.38.1737992096302; Mon, 27 Jan 2025 07:34:56 -0800 (PST) MIME-Version: 1.0 References: <20250127152534.GR10433@brightrain.aerifal.cx> In-Reply-To: <20250127152534.GR10433@brightrain.aerifal.cx> From: enh Date: Mon, 27 Jan 2025 10:34:45 -0500 X-Gm-Features: AWEUYZmiMnvbZIsxL69s5dMFqMKmGbTHaDi1j86mMx6MqM9TQJqWVhcGel64UIs Message-ID: To: Rich Felker Cc: musl@lists.openwall.com, Aditya Kumar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] fts.h On Mon, Jan 27, 2025 at 10:25=E2=80=AFAM Rich Felker wrot= e: > > 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. well, the reason i'm mentioning this is because Android's mixing in the bionic (lightly modified openbsd) fts to its host musl to be able to build various things. one of them is the bionic fts test (we build the bionic tests against the host libc too, for comparison), so we can ignore that. bionic/tests/fts_test.cpp:32:10: fatal error: 'fts.h' file not found the other two seem legit though: external/vboot_reference/futility/updater_archive.c:13:10: fatal error: 'fts.h' file not found external/selinux/libselinux/utils/selabel_get_digests_all_partial_matches.c= :7:10: fatal error: 'fts.h' file not found > 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. iirc there's a way to grep the source of all debian packages, though it would be hard to know how many of them have an alternative like ftw(3) they can use instead. > Rich