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=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 376132C500 for ; Tue, 12 Mar 2024 15:23:11 +0100 (CET) Received: (qmail 32314 invoked by uid 550); 12 Mar 2024 14:18:59 -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 30353 invoked from network); 12 Mar 2024 14:17:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1710253300; x=1710339700; bh=+p7ELJB1G+ kcYa6fNUcGeW844/48OfONzSx8YyfKpPA=; b=ZfcKhiNQXG+nHPRSjcvcYXjkI4 E530OvlMOBNzpczHMqpWVBj8bmUCBaFQkxdxXoSe4+8v3kU537syLs1YXiYVtz58 T/yNcz0kgoQz0cRmcRK2Sh40ot39UUK7IEQeio8pXJKvnAenVQtcO0UiJ64juxHw oPGu6lqDDVt5YzMesw62d4KHln3tkfYJBzruFEJsMiQeTKPce5UIAErxro0OKyVJ E5TH/mZzF1qv8FlSnF9vG6Gahf1MfLDXnAoWB7VWP3r+eis+7lhhviJ4ql2DBaV6 ezz13x6SCttJ2Wtew11+L+hFsIbOIZAcUj0QeIWZfcbzSKc6I37OZrfB7cCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710253300; x=1710339700; bh=+p7ELJB1G+kcYa6fNUcGeW844/48 OfONzSx8YyfKpPA=; b=HA3bh6Zlx7dPYZfRvQZcjiapSU8w5HCIAYWG6zLzDItO RkVUTTNiF4f/3oAYyYNCzN+UG2JTYkrB43J3sAFaIbC1zosvNuopA56gXshdHVXy vwAHRDQvEkYClrMLJP14Sfvz3LRHiUtFBtx4ZPcoqrnB1OASNDF9RjN+xysXaifm CL1p8mC9V+FTuxuplJJrq+5GS8dcGeK8XoepHEC8OErUKYRGCWHyvPG1zLNuUm4Q xUPnxLpmv2fseDE6MRiGN83J0b9K3U+Gs2Y8h1Kanr80JW4lN1ijg6wDwOW7wFq4 XJdQZ2JLHJktLZ1F362omjym9qhGOOOl8FNbMJ3PPA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpefhleefheduhfelgeehgeejveehueeihedvgfeuueetteelieeiteeh fefhleduieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b MIME-Version: 1.0 Message-Id: <84bf19d7-c2ba-46e7-a77d-ecc6497f08a1@app.fastmail.com> In-Reply-To: <875xxrv9mm.fsf@oldenburg.str.redhat.com> References: <20240310193956.GU4163@brightrain.aerifal.cx> <20240310234410.GW4163@brightrain.aerifal.cx> <20240311194756.GY4163@brightrain.aerifal.cx> <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> <875xxrv9mm.fsf@oldenburg.str.redhat.com> Date: Tue, 12 Mar 2024 10:21:19 -0400 From: "Zack Weinberg" To: "Florian Weimer" , "Gabriel Ravier" Cc: "Rich Felker" , "Skyler Ferrante (RIT Student)" , musl@lists.openwall.com, "Andreas Schwab" , "Alejandro Colomar" , "Thorsten Glaser" , NRK , "Guillem Jover" , "GNU libc development" , libbsd@lists.freedesktop.org, "Serge E. Hallyn" , "Iker Pedrosa" , "Christian Brauner" Content-Type: text/plain Subject: Re: [musl] Re: Tweaking the program name for functions On Tue, Mar 12, 2024, at 9:54 AM, Florian Weimer wrote: >> Doing this would break many programs, such as: >> - most of coreutils, e.g. programs like ls, cat or head, since they >> always `close` their input and output descriptors (when they've >> written or read something) to make sure to diagnose all errors > > A slightly better way to do this is to do fflush (stdout) followed by > error checking on close (dup (fileno (stdout))). Does that actually report delayed write errors? As you have it, the close() just drops the fd created by the dup(), the OFD is still referenced by fd 1 and therefore remains open. I would expect scrupulously correct and thread-safe code for detecting write errors on stdout without fd 1 ever becoming invalid to look something like this: int stub_stdout = open("/dev/null", O_WRONLY|O_CLOEXEC); if (stub_stdout < 0) perror_exit("/dev/null"); flockfile(stdout); if (ferror(stdout) || fflush(stdout)) perror_exit("stdout: write error"); int original_stdout = fcntl(fileno(stdout), F_DUPFD_CLOEXEC, 3); if (original_stdout < 0) perror_exit("dup(stdout)"); // e.g. ENFILE dup2(stub_stdout, fileno(stdout)); // failure here should be impossible close(stub_stdout); // ditto funlockfile(stdout); if (close(original_stdout) < 0) perror_exit("stdout: write error"); ... Which is enough of a pain in the neck that I can't blame people for wanting to just do close(1), especially during process termination. (I thought Linux had a "swap these two fds" mode for dup3(), which would simplify the above a bunch and get rid of one of the two places where you can hit the file descriptor limit, but it's not mentioned in my copy of the manpage. Did I just dream it?) zw