From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [104.156.224.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E5AE33B960 for ; Tue, 20 Jan 2026 16:51:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.156.224.86 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768927912; cv=none; b=YK//Q9yt8jSKGYwGvlJ/pm6BhV7K3W7NBpAbzXDJRgUAUpYYg3hDsBqmBOpUSCPC2pmAmdQccb4kBdI9PNRDF/n3JPCaqxH+sRrlBc+JEin+5nbHjnaYmR3BKlgP0EFxw94Eg8Q1OmQgr9OWicZP0hwuX24BxwTVTF6DwLBiu60= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768927912; c=relaxed/simple; bh=RRHhR59VpK2Pq3cDuEw1hfQ219ndyvVTqG3fHGZjqbs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nWEZVttwdyENbak1hIUWNWlvuBsz2CYFDgMxV3BHpbisydSQHczSdiK6yJ/UgfBCz0KOIDiRB2A2/ZaWMTTarxjOJqz6TS+q3/qdNY2j+n/wR0geLnkbRQOwvWAEI6rHg1sYlM2k+clO4LyTrqGyBAGVnofi58uT1M7sxoo5v04= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=libc.org; spf=pass smtp.mailfrom=aerifal.cx; arc=none smtp.client-ip=104.156.224.86 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aerifal.cx Date: Tue, 20 Jan 2026 11:36:34 -0500 From: Rich Felker To: Zack Weinberg Cc: Alejandro Colomar , Vincent Lefevre , Jan Kara , Alexander Viro , 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: <20260120163634.GD6263@brightrain.aerifal.cx> 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> Precedence: bulk X-Mailing-List: linux-api@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: <60c77e5c-dbab-4cca-8d0d-9857875c73fb@app.fastmail.com> User-Agent: Mutt/1.9.5 (2018-04-13) 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. I believe my position is basically this: 1. Documentation should reflect that the EINTR behavior on raw Linux syscall and traditional glibc is non-conforming to POSIX, but make applications aware of it and that it's unsafe to retry close on these systems. 2. Documentation should be descriptive not polemic or proscriptive of coding style or practices. When there is a disagreement like this it should document that and faithfully represent the different positions, not represent the author's views on which one is correct. 3. It may be helpful to have further information on what types of errors can actually be expected from close on Linux, and under what conditions, but only if these behaviors can actually be guaranteed. If it's just documenting what Linux currently happens to do, but without any existing promise to preserve that for new file types etc., then this is stepping out of line of the role of documentation into defining the specification, and that requires input from other folks. 4. If musl behavior is being documented, it should be noted that we do not have the non-conforming EINTR issue. If the kernel produces EINTR, we return 0. From 0.9.7 to 1.1.6 we produced EINPROGRESS, but this was changed in 1.1.7 as it was found that applications would treat EINPROGRESS as an error condition. Rich