.
Last update: 1997-05-20
13210-92 #1,#14
Classification: duplicate request
These are duplicates of WG15 interpretation 9945-1-90 #23.
Refer to 9945-1-90 #23 for the response, published
in 1Q94.
_____________________________________________________________________________
Topic: fflush & EBADF
Relevant Sections: 8.1.11.1
Defect Report:
-----------------------
ISO/IEC 13210-92 #1
Assertion 6 of subclause 8.1.11.1 of ISO/IEC
13210:1994 states:
06(A) When the stream pointer argument addresses
a file descriptor that is closed, then a
call to fflush() returns a value of EOF and
sets errno to [EBADF].
Is this correct? The requirements for error
reporting for fflush() are in 8.2.3.11 of 9945-1-
1990:
If any of the functions above return an error
indication, the value of errno shall be set to
indicate the error condition. If that error
condition is one that this part of ISO/IEC 9945
specifies to be detected by one of the
corresponding underlying functions, the value of
errno shall be the same as the value specified
for the underlying function.
The C Standard says only this about error returns
from fflush():
The fflush function returns EOF if a write error
occurs, otherwise zero.
The C Standard does not specify when a write error
occurs. The unconditional requirement that
fflush() detect a bad file descriptor would seem
to go beyond the requirements of POSIX.1.
For example, if no data is present in the buffer
for the stream on which fflush() is called, it is
conforming for fflush() to return success without
making any attempt to access the file descriptor
associated with the stream. Since there is no
need to call write() (the underlying function for
fflush()) there is no guarantee that there will be
a write error.
My feeling is that an assertion that referred to
data in the buffer would be conforming:
06(C) If the implementation supports buffered
streams:
When the stream pointer argument addresses
a file descriptor that is closed and there
is data in the buffer for the stream
pointed to, then a call to fflush()
returns a value of EOF and sets errno to
[EBADF].
WG15 13210-92 #14:
The ISO/IEC 13210:1994 has the following assertion for
fflush():
06(A) When a stream pointer argument addresses a file descriptor
that is closed, then a call to fflush() returns a value of
EOF and sets errno to [EBADF].
The corresponding test in the NIST PCTS 151-2 beta test
suite has a test strategy as follows:
fd = Zopen(path, O_RDONLY | O_CREAT, PROT_ALL);
sfd = Zfdopen(fd, "r");
Zclose(fd);
expecting(EOF);
expecting(EBADF);
Zfflush(sfd);
The problem is the requirement that this strategy places
that fflush() return -1 in this case when we have a read
stream.
Rationale:
For write streams, fflush() has to be sure that any buffered
data is written. For read streams, fflush() has to discard
any buffer contents and adjust the current seek address.
For read/write streams, fflush() has to enable a change in
I/O direction. Given that in the above code fragment there
is no underlying operation to perform (there isn't even a
buffer, let alone any contents to ignore), there should not
be a requirement to return an EBADF error.
Only the C standard and 9945-1 own the rules for fflush().
There is no requirement that we can find in either that
corresponds to the above. Moreover, the above would require
adding an otherwise useless system call to fflush(). Think
about the precedent that this would set: Theoretically,
this would imply that, unless granted immunity, each stdio
function would have to do test-the-file- descriptor code
whenever it didn't happen to get to an underlying operation
that would do the verification already.
All the test assertions in 13210 are supposed to follow
directly from 9945-1 statements. The assertion quoted above
has no basis in POSIX.1. We recommend that this assertion
not apply to read streams.
WG15 response for 13210:1994
--------------------------------------------------
The interpretation for ISO/IEC 9945-1:1990 #23 applies to these
requests : ISO/IEC 13210-92 #1, and ISO/IEC 13210-92 #14.
Rationale for Interpretation:
-----------------------------
See ISO/IEC 9945-1:1990 #23.
_____________________________________________________________________________