Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001225 [1003.1(2016)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2019-01-12 20:39 2019-01-12 20:39
Reporter osoong View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Oliver Soong
Organization
User Reference
Section fseek, fsetpos
Page Number 957-961
Line Number 32543-32545, 32575, 32584, 32670
Interp Status ---
Final Accepted Text
Summary 0001225: flushing while seeking on memory buffer streams
Description fseek(), fseeko(), and fsetpos() apply to streams opened with fmemopen(), open_memstream(), and open_wmemstream(). fseek() and fseeko() are required to write unwritten buffered data to the underlying file. Does this mandated flushing behavior apply to memory streams? If so, the verbiage around lines 32543-32545 might need some clarification. Regardless of whether the flushing is mandated, I think some error codes should be added since flushing may still occur. It might also be helpful to add the memory buffer functions under "See Also".

Modifying lines 32543-32545 to apply to both files and memory buffer streams while still being clear is a bit tricky. I think it's easier to modify line 32543 to begin, "If the stream is backed by a file and is writable, and buffered data...". Then, at line 32545, add "If the stream was created by fmemopen(), open_memstream(), or open_wmemstream(), and if the stream is writable, and if data in the stream's I/O buffer had not been written to the underlying memory buffer, fseek() shall cause the unwritten data to be written to the underlying memory buffer."

I also think there should be entries for ENOSPC and ENOMEM errors similar to those given for fflush() (page 859, lines 28982-28985). If flushing memory streams is mandated, then they should be "shall fail" errors (page 958, line 32575), and if flushing is not mandated, then "may fail" would be more appropriate (page 958, line 32584). For reference, the errors are:


[ENOMEM] The underlying stream was created by open_memstream() or open_wmemstream() and insufficient memory is available.
[ENOSPC] There was no free space remaining on the device containing the file or in the buffer used by the fmemopen() function.


There is no explicit requirement that fsetpos() write unwritten buffered data in either the C or POSIX standard. Although the C99 rationale is not formally part of the standard, it does state that fsetpos() "assure[s] that the I/O buffer has been flushed" (7.19.5.3). I'm not sure what exactly should be done there. Perhaps add "may fail" entries at page 961 line 32670?

Finally, it might also be useful to add entries for fmemopen(), open_memstream(), and open_wmemstream() under the See Also heading at page 958 line 32595 for fseek() and fseeko() and maybe at page 961 line 32681 for fsetpos().
Desired Action page 957, line 32543: Replace "If the stream is writable and..." with "If the stream is backed by a file and is writable, and...".

page 957, line 32545: Append "If the stream was created by fmemopen(), open_memstream(), or open_wmemstream(), and if the stream is writable, and if data in the stream's I/O buffer had not been written to the underlying memory buffer, fseek() shall cause the unwritten data to be written to the underlying memory buffer."

Copy the ENOMEM and ENOSPC entries from fflush() (page 859, lines 28982-28985) to fseek() and fseeko(), either as "shall fail" errors (page 958, line 32575) or as "may fail errors (page 958, line 32584).

page 958, line 32595: Add fmemopen(), open_memstream(), and open_wmemstream() under the "See Also" heading.

page 960, line 32670: Maybe copy the same entries to fsetpos() as "may fail" errors.

page 961, line 32681: Maybe add fmemopen(), open_memstream(), and open_wmemstream() under the "See Also" heading.
Tags No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2019-01-12 20:39 osoong New Issue
2019-01-12 20:39 osoong Name => Oliver Soong
2019-01-12 20:39 osoong Section => fseek, fsetpos
2019-01-12 20:39 osoong Page Number => 957-961
2019-01-12 20:39 osoong Line Number => 32543-32545, 32575, 32584, 32670


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