Defect report from : Don Cragun , Sun Microsystems, Inc.
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 430 line 14134-14144 section freopen objection {dwc-freopen.20030806}
Problem:
Edition of Specification (Year): 2003
Defect code : 3. Clarification required
The ability to pass a null pointer to freopen() as a filename operand
was added to C99 and inherited by this standard from there. In this
standard P430, L14141-14144 (as well as in the C standard), it says:
"If filename is a null pointer, the freopen() function
shall attempt 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".
The paragraph in this standard on P430, L14134-14136:
"The freopen() function shall first attempt to flush
the stream and close any file descriptor associated
with stream. Failure to flush or close the file
descriptor successfully shall be ignored. The error
and end-of-file indicators for the stream shall be
cleared."
corresponds to the last paragraph in the description of freopen()
in the C Standard (subclause 7.19.5.6, paragraph 4):
"The freopen function first attempts to close any
file that is associated with the specified stream.
Failure to close the file is ignored. The error and
end-of-file indicators for the stream are cleared."
Note that in the C Standard, there are no file descriptors only files
referenced by the FILE * returned by fopen() and freopen(). Note also
that in the C Standard, this paragraph about closing the file
associated with the specified stream follows the paragraph saying
that when filename is a null pointer, it is implementation-defined
which changes of mode are permitted (if any) and under what
circumstances.
It is my belief that a perfectly reasonable implementation of
freopen(NULL, mode, stream) would allow the stream (or FILE *) to be
reinitialized without actually closing the underlying file
descriptor. (Given POSIX semantics of destroying a file whose last
link has been removed from the filesystem on last close, this is
absolutely necessary if freopen() is to succeed on such files.
If the intent were that the underlying file descriptor
actually had to be closed, there would be no reason to have
implementation-defined behavior for mode changes; implementations
would essentially be required to fclose(stream) and
fopen(name_of_file_previously_associated_with_stream, mode) and be
sure that the returned stream was the original stream pointer. If
the fopen() succeeded, you would have the requested mode with no
implementation-defined behavior required. If the fopen() failed, the
freopen() would fail! In either case, the stream has essentially
been closed and reopened whether the underlying file descriptor is
closed or not.)
Unfortunately, at least one test suite has been written assuming that
the requirement to close the file descriptor associated with the
stream applies even if the filename pointer is null. We need an
interpretation or clarification of the standard to make this clear.
Action:
Add a sentence to the paragraph on P430, L14141-14144 so that the
updated paragraph is:
"If filename is a null pointer, the freopen() function
shall attempt 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. In this case,
the file descriptor associated with the stream need not
be closed if the call to freopen() succeeds. It is
implementation-defined which changes of mode are
permitted (if any) and under what circumstances".
Since other parts of the description of freopen() that talk about
the file descriptor (which is not mentioned in the C Standard) are
not CX shaded, I don't know if this new sentence should be CX shaded
or left unshaded. The new sentence does not change any C Standard
required behavior.
|