RFR [8055421]: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

[Ivan Gerasimov]

On 22.08.2014 3:30, Martin Buchholz wrote:
> Ivan, I think your change for fclose is incorrect, you are discarding 
> the handling for errno = EINTR.
> I don't think any man page could be serious about not calling fclose 
> again if it returned with errno = EINTR!
>
I've checked man pages on Linux, Solaris and MacOS and they all seem to 
be consistent:

Linux: Upon successful completion 0 is returned.  Otherwise, EOF is 
returned and the global variable errno is set to indicate the error.
In either case any further access (including another call to fclose()) 
to the stream results in undefined behavior.

Solaris: After the call to fclose(), any use of stream  causes undefined 
behavior.

MacOSX: Upon successful completion 0 is returned.  Otherwise, EOF is 
returned and the global variable errno is set to indicate the error.
In either case no further access to the stream is possible.


I've also checked some of the implementations available around:
[1] https://github.com/lattera/glibc/blob/master/libio/iofclose.c
[2] 
http://www.opensource.apple.com/source/Libc/Libc-167/stdio.subproj/fclose.c
[3] 
https://code.google.com/p/android-source-browsing/source/browse/libc/upstream-freebsd/lib/libc/stdio/fclose.c?repo=platform--bionic&r=6b05c8e28017518fae04a3a601d0d245916561d2

In these the internal buffer is freed no matter what the result of 
close() was.
Repeated call to fclose upon a failure doesn't seem to hurt, but should 
not be needed.

Sincerely yours,
Ivan