RFR [8055421]: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
Ivan Gerasimov
ivan.gerasimov at oracle.com
Fri Aug 22 05:35:11 UTC 2014
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
More information about the nio-dev
mailing list