Thank-you to Clive and Fred for their feedback on the reasons
freopen(NULL, ...) was added to the C Standard.
Now that I know the main purpose is for switching between
text and binary modes, I think that it doesn't matter much
how the underlying file descriptor is handled, as long as C99
programs which use the feature are portable to POSIX systems.
I propose that we specify only the aspects that are covered by
the C Standard and leave the rest mostly unspecified. (I'm
assuming there is zero chance that the C Standard will change
its requirements in a TC.) The following is a rough outline - if
we can agree which things to specify (and which to state are
unspecified) then we can work on some appropriate wording.
Specify:
* any unwritten buffered data are written
* new modes "r" and "r+" rewind the stream; "w" and "w+" rewind, truncate
and clear O_APPEND; "a" and "a+" set O_APPEND
* error and end-of-file indicators are cleared
* orientation is cleared
* mbstate_t object is set to initial conversion state
* if the mode change is not permitted, the call returns NULL and sets
errno to EINVAL
Leave unspecified:
* whether the fd underlying the stream changes to the lowest numbered
unused fd
* whether the access mode of the underlying fd is changed (as long as
it permits the access implied by the new stream mode)
* whether O_NONBLOCK is cleared
* whether FD_CLOEXEC is cleared
* whether the stream's encoding rule is cleared
* whether the offset maximum is changed
Not sure:
* whether to specify that changes which only add or remove a "b" are
always permitted
* whether the actions specified in the description of close() occur for
the underlying fd
This last item is probably the most difficult to resolve. If the
actions of a close() occur, then this could have unwanted effects on
a simple C99 program that just wants to ensure it is reading/writing
stdin/stdout in binary mode. In particular if stdout is a pipe then
the reader would get EOF, and if stdin is a pipe then the writer
would get a SIGPIPE (or EPIPE error). It also has implications for
what happens if the file is a regular file with a link count of 0
(the call could fail with ENOENT?)
Perhaps we should say that whether the actions of close() on the
underlying fd occur is unspecified except that the actions associated
with a last close do not occur, even if only one file descriptor is
open for the file.
--
Geoff Clare <yyyyyyy@xxxxxxxxxxxxx>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
|