Given that the standard states
[EINTR]
The fclose() function was interrupted by a signal.
I think it's safe to say that fclose is allowed to fail with no defined way to clean up the mess.Yeah, I was just looking at that after I posted my initial comment, and I think I agree with you. That's the only reading I can see that doesn't create more questions than it answers.
I think in this case, Occam's razor says "this part of the standard is not fully thought through".
this part of the standard is not fully thought through
I agree... and this terrifies me, given that EINTR is mentioned in the man page for close(2) back in BSD Net/2, over 20 years ago.
this terrifies me
Now think about all the libraries and application that end up calling close() and fclose().
Add a few abstraction layers and good luck figuring out if closing a file is safe in a multithreaded Java app.
It is somewhat unrelated, but you might enjoy Jim Meyering's "Goodbye, world: the perils of relying on output streams in C":
https://www.irill.org/events/ghm-gnu-hackers-meeting/videos/...
And as part of the C standard, we have "After the call to fclose(), any use of stream results in undefined behavior.".
Uh-oh. So does this imply that fclose(), at least, has to do the job right, or does it mean it inherits the close() flaw, and leaves no defined way to try and clean up the mess?
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fc...