|Anonymous | Login||2019-04-18 16:36 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000626||[1003.1(2008)/Issue 7] System Interfaces||Editorial||Clarification Requested||2012-10-25 05:39||2019-01-11 23:03|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||see Note: 0001418|
|Summary||0000626: Unclear whether fflush(0) and/or exit() affect memory streams|
fflush(0) is specified according to:
"If stream points to an output stream or an update stream in which the most recent operation was not input, fflush() shall cause any unwritten data for that stream to be written to the file, [CX] and the last data modification and last file status change timestamps of the underlying file shall be marked for update.
If stream is a null pointer, fflush() shall perform this flushing action on all streams for which the behavior is defined above."
However, the action of fflush(stream) where stream is a memory stream (obtained by fmemopen, open_memstream, or open_wmemstream) is not "defined above" but defined under the description of those three functions. Is it the intent of the standard to require fflush(0) to act on memory streams? Obviously there is some benefit to implementations in avoiding the lock-contention cost of tracking open memory streams along with open streams referring to actual files, and if the main use of fflush(0) is to ensure that data is written to disk before calling _exit/_Exit, it seems unnecessary to require that fflush(0) flush memory streams. However, it would be possible to write a program that depends on fflush(0) flushing memory streams. I have not researched the behavior of existing implementations to see what the precedent is.
Similarly, exit() is specified to "flush all open streams with unwritten buffered data and close all open streams"; this language seems less doubtful as to whether memory streams are included, and seems to imply that a thread holding a lock on a memory stream could cause another thread calling exit() to be suspended indefinitely, despite the fact that the side effects of closing memory streams will not be observable when the program exits.
Clarify whether memory streams are included in the behavior required for fflush(0) and exit(), and update the language (at least for fflush) to account for the addition of memory streams to the standard.
edited on: 2012-11-07 17:15
The standard is clear that memory streams opened for output are a subset of output streams, and therefore the requirements of fflush() already apply (in other words, yes, it is required that an application can block exit() while waiting for a flush operation on an output memory stream). See XSH 2.5, page 491, lines 16814-16822.
However, we also note that the requirement of fflush() mentions updating the timestamps of the underlying file, and a memory stream has no underlying file. As such, we propose the following change, clarifying all stream operations that talk about updating timestamps:
At XBD 4.8, page 109, prior to line 2917, add a new paragraph:
Many operations have requirements to update file timestamps. These requirements do not apply to streams that have no underlying file description (for example, memory streams created by open_memstream() have no underlying file description).
At XSH fflush, page 844, line 28023, change "For a stream open for reading," to "For a stream open for reading with an underlying file description,"
|2012-10-25 05:39||dalias||New Issue|
|2012-10-25 05:39||dalias||Status||New => Under Review|
|2012-10-25 05:39||dalias||Assigned To||=> ajosey|
|2012-10-25 05:39||dalias||Name||=> Rich Felker|
|2012-10-25 05:39||dalias||Organization||=> musl libc|
|2012-10-25 05:39||dalias||Section||=> fflush, exit|
|2012-10-25 05:39||dalias||Page Number||=> unknown|
|2012-10-25 05:39||dalias||Line Number||=> unknown|
|2012-11-07 16:41||eblake||Relationship added||related to 0000611|
|2012-11-07 17:03||eblake||Note Added: 0001418|
|2012-11-07 17:04||eblake||Page Number||unknown => 844|
|2012-11-07 17:04||eblake||Line Number||unknown => 28021|
|2012-11-07 17:04||eblake||Interp Status||=> ---|
|2012-11-07 17:04||eblake||Final Accepted Text||=> see Note: 0001418|
|2012-11-07 17:04||eblake||Status||Under Review => Resolved|
|2012-11-07 17:04||eblake||Resolution||Open => Accepted As Marked|
|2012-11-07 17:06||eblake||Note Edited: 0001418|
|2012-11-07 17:12||eblake||Note Edited: 0001418|
|2012-11-07 17:15||eblake||Note Edited: 0001418|
|2012-11-07 17:22||geoffclare||Tag Attached: tc2-2008|
|2019-01-11 19:37||osoong||Issue Monitored: osoong|
|2019-01-11 19:38||osoong||Issue End Monitor: osoong|
|2019-01-11 23:03||eblake||Relationship added||related to 0001156|
|2019-01-14 16:57||geoffclare||Relationship replaced||has duplicate 0001156|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|