Notes |
(0006893)
geoffclare (manager)
2024-09-26 16:12
|
Interpretation response
------------------------
Regarding the use of freopen() with a non-null pathname, the standard clearly states that freopen() first attempts to flush the stream then closes any file descriptor associated with the stream, and conforming implementations must conform to this.
Regarding the use of freopen() with a null pathname on a stream that has an associated file descriptor, the standard clearly states that the file descriptor associated with the stream need not be closed if the call to freopen() succeeds and that it is implementation-defined which changes of mode are permitted (if any), and under what circumstances, and conforming implementations must conform to this.
Regarding the use of freopen() with a null pathname on a stream that does not have an associated file descriptor, the standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.
Rationale:
-------------
There are unusual but valid use cases where a stream opened with popen() would not be closed with pclose(), such as forking after popen() and using fclose() or freopen() on the stream in the child. Another use case would be if an application wants to be able to detect that the child started by popen() was stopped by a signal. It would need to find out the process ID by some means (e.g. read it from the stream) but it could then call waitpid() and either fclose() or freopen() instead of using pclose().
On memory streams, with a non-null pathname the standard uses "if any" in the stated requirement about an associated file descriptor. However, with a null pathname there are references to the associated file descriptor which assume there is one.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 1030 line 35294 section freopen(), change:
In this case, the file descriptor associated with the stream need not be closed if the call to freopen() succeeds.
to:
In this case, if there is a file descriptor associated with the stream, it need not be closed if the call to freopen() succeeds.
On page 1030 line 35313 section freopen(), change:
The file descriptor underlying the stream is not a valid file descriptor when pathname is a null pointer.
to:
The file descriptor associated with the stream, if any, is not a valid file descriptor when pathname is a null pointer.
On page 1031 line 35351 section freopen(), change:
The mode with which the file descriptor underlying the stream was opened does not support the requested mode when pathname is a null pointer.
to:
The mode with which the file descriptor associated with the stream, if any, was opened does not support the requested mode when pathname is a null pointer.
After page 1032 line 35390 section freopen(), add a paragraph to APPLICATION USAGE:
The use of freopen() on streams opened with open_memstream() or open_wmemstream() is discouraged, as some of the requirements stated in the description of those functions are conditional on there having been a successful fflush() or fclose() on the stream. These cannot be relied upon if freopen() is used (without first doing an explicit fflush()) because freopen() ignores failure of the flush operation. |
|
(0006894)
agadmin (administrator)
2024-09-27 08:43
|
Interpretation proposed: 27 September 2024 |
|
(0006910)
gbrandenrobinson (reporter)
2024-10-10 16:00
|
Re: note 6893:
Speaking as a lay person only glancingly familiar with standardese:
"Regarding the use of freopen() with a null pathname on a stream that has an associated file descriptor, the standard clearly states that the file descriptor associated with the stream need not be closed if the call to freopen() succeeds and that it is implementation-defined which changes of mode are permitted (if any), and under what circumstances, and conforming implementations must conform to this."
I find that paragraph hard to interpret. I infer two stipulations:
1. the file descriptor associated with the stream NEED NOT be closed if freopen() succeeds; and
2. changes of mode under such a circumstance are completely at the discretion of the implementation.
When I try to deduce what behavior "must be" conformed with thus, I am at a loss. You can close the descriptor, or not, and you will be conformant. You can change some, none, or all file modes, and you will be conformant.
It seems like there is no requirement to conform to here.
Can someone illuminate the matter? |
|
(0006911)
geoffclare (manager)
2024-10-10 16:31
|
> It seems like there is no requirement to conform to here.
When behaviour is "implementation-defined", the implementation is required to document the behaviour. |
|
(0006950)
agadmin (administrator)
2024-11-07 16:39
|
Interpretation approved: 7th November 2024 |
|