Hi Ted, Rich, On Fri, May 16, 2025 at 09:05:47AM -0400, Rich Felker wrote: > FWIW musl adopted the EINPROGRESS as soon as we were made aware of the > issue, and later changed it to returning 0 since applications > (particularly, any written prior to this interpretation) are prone to > interpret EINPROGRESS as an error condition rather than success and > possibly misinterpret it as meaning the fd is still open and valid to > pass to close again. Hmmm, this page will need a kernel/libc differences section where I should explain this. On Fri, May 16, 2025 at 10:20:24AM -0400, Theodore Ts'o wrote: > On Fri, May 16, 2025 at 09:05:47AM -0400, Rich Felker wrote: > > > In general, raw kernel interfaces do not conform to any version of > > POSIX; they're just a low-impedance-mismatch set of inferfaces that > > facilitate implementing POSIX at the userspace libc layer. So I don't > > think this should be documented as "Linux doesn't conform" but > > (hopefully, once glibc fixes this) "old versions of glibc did not > > conform". > > If glibc maintainers want to deal with breaking userspace, then as a > kernel developer, I'm happy to let them deal with the > angry/disappointed users and application programmers. :-) Which breakage do you expect from the behavior that musl has chosen? I agree that the POSIX invention of EINPROGRESS is something that would break users. However, in removing the error completely and making it a success, I don't see the same problem. That is, if a program calls close(2) and sees a return of 0, or sees a return of -1 with EINTR on Linux, both mean "the file descriptor has been closed, and the contents of the file will *eventually* reach the file". In which cases do you expect any existing Linux program to behave differently on 0 and on EINTR? Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
