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 0437527338 for ; Tue, 12 Mar 2024 21:45:45 +0100 (CET) Received: (qmail 13735 invoked by uid 550); 12 Mar 2024 20:41:31 -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 32312 invoked from network); 12 Mar 2024 19:21:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding: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=1710271552; x=1710357952; bh=cMEeZGIEj1PGmKOXJ/LPcHVbcEcwzo+hKGiGFXEyvxM=; b= nbmgUjcuidYQk9yC7G3Phh5eR5mG7G1jr475GlRo0IfyqphAC7muZlDbryAtmMOQ k/qc6T+r18NM4+8g8uyNEQKMS4jsHy6FZs54wuv20TMIFSd+sV74XXiT0uXqQF5n sHZJzRG3llAmLzdG+v56w4yWp4fo1pSnriJgul1N/kaf2OWiMFJNQulSip2PDBAn uRUzd+vgO02BndgJTsgXdoB8iazDBe/g52mnC2jrz9krzGWMhsVW9Sb9UFYKibLI mtj8FkhqAgEhTG5uyLhHjIvsuA6NaLXos8/nCAhmHRfZhi+wFcRAQiOgoXfq6o5F w/W/X+rKyamqnUIJMkrCaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=1710271552; x= 1710357952; bh=cMEeZGIEj1PGmKOXJ/LPcHVbcEcwzo+hKGiGFXEyvxM=; b=d B5tvxFIIwU/KyRJil7yAKMpJGxnSFdIWQ/9b3dQc3fSCz6G1UKz1qPYvmkStRYir wgGHltXbRZhZT+UrAwzrfUBztvCJfFBBC9leZESbqoExLahyPmQvAel+Y8NDqf+u 0EA0YGbGWEuyP8/9qSiE9jJ6tElN6/o+Qudj60bCuqb9lWxb7NRwK8y1RTi+QALb 7pOTPAV8r6h98uYzz702NiU8ibwieoEZS8XrD/PmASwRY7jYDBazMK19FBWYwyUX qRlsBTkzcooYxksYFpx1CoJDYESnVbAQBUdxCtp/IZ37BdSPytthcXIJG3UXoiym ZfjnJ32ZfAgbKhp9my8lg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeefgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdgk rggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenuc ggtffrrghtthgvrhhnpeduueeigeehffekiefhtdehiedvueffteevtefhudfguedtueei tdetgfetieeiieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpeiirggtkhesohiflhhfohhlihhordhorhhg 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: <180c5e67-5e97-4ac8-ab7c-696d2aa865ed@app.fastmail.com> In-Reply-To: <20240312144225.GC4163@brightrain.aerifal.cx> References: <20240311194756.GY4163@brightrain.aerifal.cx> <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> <875xxrv9mm.fsf@oldenburg.str.redhat.com> <84bf19d7-c2ba-46e7-a77d-ecc6497f08a1@app.fastmail.com> <87o7bjttcn.fsf@oldenburg.str.redhat.com> <20240312144225.GC4163@brightrain.aerifal.cx> Date: Tue, 12 Mar 2024 15:25:31 -0400 From: "Zack Weinberg" To: "Rich Felker" , "Florian Weimer" Cc: "Gabriel Ravier" , "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;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Re: Tweaking the program name for functions On Tue, Mar 12, 2024, at 10:42 AM, Rich Felker wrote: > On Tue, Mar 12, 2024 at 03:31:04PM +0100, Florian Weimer wrote: >> * Zack Weinberg: >>=20 >> > 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 th= ey >> >>> 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. >>=20 >> I don't think the VFS close action is subject to reference counting. >> Otherwise the current coreutils error checking wouldn't work because = in >> many cases, another process retains a reference to the OFD. > > It is. close only reports errors if it's the last fd referring to the > ofd. It's an incredibly stupid design choice by NFS that mismatches > expected fd behavior.=20 I do fully agree that this is a design error in NFS and in close(2) more= generally [like all destructors, it should be _impossible_ for close to= fail], but there is no realistic prospect of changing it, and I've been= burned a few times by programs that didn't notice delayed write errors.= The risk of missing an error because another process still has a ref to= the OFD is real, but it comes up rarely enough that I don't think it sh= ould deter us from trying to get the "only one process has this file ope= n" case right. (Think shell `>` redirection.) Also, I have written programs that expected fds 0 and/or 1 to be pipes, = and closed them well before exiting as a cheap way to send one-shot even= ts to the process on the other end of the pipe. I think that's a legitim= ate way to use inherited fds, and it would be significantly more difficu= lt to do in some contexts if you had to use a fd > 2 to do it (e.g. the = process on the other end used popen() to start things). If there's something we can do to make it easier for programmers to do t= he Right Thing with closing standard fds, IMHO we should. For stdio, we = perfectly well _could_ special case fclose(), when the fileno is 0/1/2, = to do the dup/close dance and leave both the FILE and the fd in a valid,= stubbed state. (For stdin, open("/dev/null", O_RDONLY) is clearly an ap= propriate stub semantic; for stdout and stderr I am unsure whether "disc= ard all writes silently" or "fail all writes" would be better.) I don't = think it's safe to make close() special case 0/1/2, though=E2=80=94not l= east because it's supposed to be atomic and async signal safe. And we sh= ould maybe give some thought to runtimes for languages other than C, whi= ch probably have their own buffering wrappers for fds 0/1/2 and might ca= re about cross-language interop. zw