Andrew Josey <yyyyyy@xxxxxxxxxxxxxxxxx> wrote, on 29 Aug 2003:
>
> Subject: Minutes of the 28 Aug Teleconference
>
> XSH ERN 142 Accept
> Don had checked with the chair of the C standards committee
> and he had agreed with the proposed change.
The proposed changes are definitely needed, and I doubt if anyone
would disagree with them.
However, the problem is that even with those changes the requirements
are still unclear.
I think that to resolve this we need to ask the C Standard folks about
the reasons behind this addition in the C Standard. At the moment I
don't have any feeling for how they intended it to work, or how it
is meant to be used. I also have questions about what the exact
requirements of the C Standard on freopen(NULL, ...) are.
First the questions about the background for the addition:
1. Was freopen(NULL, ...) added to the C Standard in order to provide
applications with a way of completely re-initialising a stream without
needing to know the file name? Or is the whole point just the mode
change, with other effects considered secondary? I'm thinking that
maybe the idea is that an application which opens a file read-write to
write some data that it will then read back could change the mode to
read-only after it has written the data. Is that the kind of use that
was envisaged, or something else?
2. Was the new feature based on an existing implementation? If so,
what kind of implementation is it - in particular does it have
something like a POSIX file descriptor underlying stdio streams?
If it has an underlying fd, does freopen(NULL, ...) change the
properties of the fd?
Now about the requirements of the C Standard. As a reminder the text
in question is:
"If filename is a null pointer, the freopen function attempts to
change the mode of the stream to that specified by mode, as if the
name of the file currently associated with the stream had been
used. It is implementation-defined which changes of mode are
permitted (if any), and under what circumstances."
3. Is the "as if" here intended to encompass properties of stdio streams
beyond those specified in the C Standard? E.g. must the effects of
these two call sequences be identical in every way (assuming "r+" -> "r"
is a permitted mode change, and the name "myfile" still refers to the
same file when the freopen() call in sequence A is made):
A. fp = fopen("myfile", "r+");
putc('X', fp);
freopen("myfile", "r", fp);
B. fp = fopen("myfile", "r+");
putc('X', fp);
freopen(NULL, "r", fp);
or does the C Standard make no requirements other than that the 'X' is
written to the file, the mode of the stream is changed to "r" and the
file position indicator for the stream is set to the beginning of
the file?
[In POSIX we might want to say that the access mode of the underlying
fd need not change, or that the FD_CLOEXEC flag is retained, but we
can't do that if it would conflict with the requirements of the
C Standard. I'm also wondering what implications this has for file
types other than plain files, e.g. for a FIFO open for writing should
another process reading the FIFO get EOF, for a connected socket
should the connection be dropped?]
4. What happens if freopen(NULL, ...) is called with the same mode
that the stream already has? Strictly speaking this is not a "change"
of mode, so when the standard says "It is implementation-defined which
changes of mode are permitted (if any), and under what circumstances",
it is not clear how this applies to calls with the same mode.
One possible interpretation is that because freopen() "attempts to
change the mode", when the same mode is requested it cannot "change"
the mode, so the call must fail.
5. What is the required behaviour when a mode change that is not
permitted by the implementation is attempted? Must the freopen() call
return NULL, or is the behaviour undefined?
--
Geoff Clare <yyyyyyy@xxxxxxxxxxxxx>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
|