Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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-06-10 08:55
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Rich Felker
Organization musl libc
User Reference
Section fflush, exit
Page Number 844
Line Number 28021
Interp Status ---
Final Accepted Text see Note: 0001418
Summary 0000626: Unclear whether fflush(0) and/or exit() affect memory streams
Description 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.
Desired Action 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.
Tags tc2-2008
Attached Files

- Relationships
related to 0000611Closedajosey 1003.1(2008)/Issue 7 Interaction of exit with stdio stream locking is not specified 
has duplicate 0001156Closed 1003.1(2016/18)/Issue7+TC2 Should fflush (NULL) flush streams not backed by files? 

-  Notes
eblake (manager)
2012-11-07 17:03
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,"

- Issue History
Date Modified Username Field Change
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
2019-06-10 08:55 agadmin Status Resolved => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker