From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BF1C47884B; Tue, 20 Jan 2026 19:15:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768936554; cv=none; b=EHybUfItC/shOT5SZRGIkbXX+R5siXuqVV4xS61rj9xfK30uRxw6HUlyDl1x0VYFCU18z5JROBDxnnR/ZvTtWjD0W0rpbJAFnjUnno0eItnGZ3OeGBoetlfY9qifVic+vDoVwlAM7Ows8d/DK4FV6KyMaeH2OCFwA83u5NXmBUc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768936554; c=relaxed/simple; bh=t8z3Rwu7qOd+nhn4EsS5Aj8jJGv7Rw2YMqx/E2B1zZ0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=V0ijfCNi2z45DFxb0Ab8rZI2A65LfoDU8lUzVRatZlJqMHiXkkK1x2scoVysnfRlZ9BWd59Bw3yWEmlEMjGXXP0R+AR0apMjtIUnUDwJ7og/tl/42dfxF7eKqR91vtvrk+Mr+COHu9G347ElheCtSjXiDp0hUGta6omqZYAB/Nk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=PfDYkCH1; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="PfDYkCH1" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=DjMUgMTbUmtrrp7aKjAsaMnjZcwTC03kGRkrVlxFZoY=; b=PfDYkCH1fMpw3iQS78xl3lkl1X +UKJO0a1+Zw6GZWasBeoJ66ZHOb/1juI+qpE0DMbQodRCgR4vYJ1MoT9wNaIhxQTK8hN3SYuJEp7t 6n274mf1jgWeUAp4lI3LMtZTeNuEsdv8WtjMiKvm92kkKxCAMzJHh/UynAMnHyqSDDfjExly6X6yD 0OqYepr9gvvmTLq7v8mVfgXrEmkDKWBLOf2h6D9dalMtAOReXZcAOyvy5n08AVaio/xjOMQC7o7yu 4KNmUvQ/48XnKHVw1jIeyvvTsSmSCbGJj4lF0ssx4iXQrEq5xoySsQFD2lDtgwj24BZoj7LZr6vsW Bt/LYm4Q==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99 #2 (Red Hat Linux)) id 1viHEB-0000000DMsh-0cwj; Tue, 20 Jan 2026 19:17:23 +0000 Date: Tue, 20 Jan 2026 19:17:23 +0000 From: Al Viro To: Rich Felker Cc: Zack Weinberg , Alejandro Colomar , Vincent Lefevre , Jan Kara , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, GNU libc development Subject: Re: [RFC v1] man/man2/close.2: CAVEATS: Document divergence from POSIX.1-2024 Message-ID: <20260120191723.GA3183987@ZenIV> References: <20250516130547.GV1509@brightrain.aerifal.cx> <20250516143957.GB5388@qaa.vinc17.org> <20250517133251.GY1509@brightrain.aerifal.cx> <5jm7pblkwkhh4frqjptrw4ll4nwncn22ep2v7sli6kz5wxg5ik@pbnj6wfv66af> <8c47e10a-be82-4d5b-a45e-2526f6e95123@app.fastmail.com> <60c77e5c-dbab-4cca-8d0d-9857875c73fb@app.fastmail.com> <20260120163634.GD6263@brightrain.aerifal.cx> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260120163634.GD6263@brightrain.aerifal.cx> Sender: Al Viro On Tue, Jan 20, 2026 at 11:36:34AM -0500, Rich Felker wrote: > On Tue, Jan 20, 2026 at 11:15:15AM -0500, Zack Weinberg wrote: > > Rich and I have an irreconciliable disagreement on what the semantics of close > > _should_ be. I'm not going to do any more work on this until/unless he > > changes his mind. > > It's been way too long since I read this thread to recall what our > point of disagreement is or what point glibc might be at in > reconciling the Linux kernel disagreement with POSIX. It's not so much disagreement as breakage of internal POSIX decision process that has lead to POSIX irrelevance in this particular area. POSIX authority derives from the agreement of actual behaviour of Unices. Always had been, witness the amount of underspecified areas where various vendor implementation had different semantics, due to exact that reason. They (or anybody else, really) can argue that such-and-such behaviour ought to change. In quite a few cases that has succeeded. What they can't do is to force such change by fiat. Especially not when Linux and *BSD happen to agree on behaviour that differs from what they wish it to be.