Re: [RFC v1] man/man2/close.2: CAVEATS: Document divergence from POSIX.1-2024

[Rich Felker <dalias@libc.org>]

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