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
0000657 [1003.1(2008)/Issue 7] System Interfaces Objection Clarification Requested 2013-02-08 22:46 2013-03-28 23:54
Reporter philip-guenther View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Philip Guenther
Organization OpenBSD
User Reference
Section fmemopen
Page Number 867
Line Number 28775
Interp Status ---
Final Accepted Text
Summary 0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified
Description As updated by XSH/TC1/D3/0149, the fmemopen() description now states:

 When a stream open for writing is flushed or closed, a null byte shall
 be written at the current position or at the end of the buffer, depending
 on the size of the contents. If a stream open for update is flushed or
 closed and the last write has advanced the current buffer size, a null
 byte shall be written at the end of the buffer if it fits.

The first sentence does not specify _how_ the choice of where to write the NUL depends on the size of the contents. Therefore, an implementation is presumably conforming if it writes the NUL to the current position whenever the size of the contents is an even number, and to the end of the buffer when it is odd, for example.

The second sentence only indicates that a NUL is (required to be) written if the last write advanced the current buffer size. So, a program that does a write which advanced the buffer size, then seeks back and does another write, and _then_ flushes or closes it cannot depend on a NUL to be written.
Desired Action Provide an actual specification for when and where the NUL is written in the "open for writing" case, presumably something about the minimum of the two offsets.

Change the second sentence to match what seems to be the glibc behavior:
 If a stream open for update is flushed or closed and the current buffer
 size has been advanced by a write since the stream was opened or flushed,
 a null byte shall be written at the end of the buffer if it fits.

Tags No tags attached.
Attached Files

- Relationships
related to 0000396Closedajosey 1003.1(2008)/Issue 7 fmemopen vs. 'b' mode flag 
related to 0000456Appliedajosey 1003.1(2008)/Issue 7 mandate binary mode of fmemopen 
related to 0000818Closed 1003.1(2013)/Issue7+TC1 fmemopen should allow 0-size buffer 

-  Notes
(0001506)
philip-guenther (reporter)
2013-03-28 23:54

Another spot or two where glibc and the standard disagree:
    http://sourceware.org/bugzilla/show_bug.cgi?id=15298 [^]

I'm not sure why the text for these interfaces was put in the standard, given that the words apparently had little to do with the implementation that existed at the time. It's not clear they're converging either.

Might I suggest that if single-sourced APIs are going to be pulled into the standard, that that source be consulted with to verify what part of them can be considered stable for inclusion (vs left as unspecified or undefined behavior) and what level of "change control" they're willing to pass over? Is the submission done with the desire to improve the original implementation from the feedback (I think the *at() API family was like this) or is it pretty much cast in stone? If the final spec doesn't match the implementation, is the implementation going to change or will the spec need to change?

If the answer from the glibc people is "we'll update to match the requirements of the spec in a future release", all the better for POSIX. If their answer is "the spec is wrong on these points, but we'll work with you to bring the spec in line in a timely fashion with what we say the behavior is", that would be wonderful too, because then we would at least have a spec that matched reality.

If their answer is "sorry, we got here first and have too many apps depending on their current behavior and/or may make future changes to their behavior without consultation", then these interfaces should be deprecated from the spec with a note about why...so that the other existing implementations can go shred those pages in their copies of POSIX and then reverse engineer what glibc is doing.

Lacking visible word from the glibc maintainers on this, my assumption is that the latter is the case, but no one wants to actually say it.

- Issue History
Date Modified Username Field Change
2013-02-08 22:46 philip-guenther New Issue
2013-02-08 22:46 philip-guenther Status New => Under Review
2013-02-08 22:46 philip-guenther Assigned To => ajosey
2013-02-08 22:46 philip-guenther Name => Philip Guenther
2013-02-08 22:46 philip-guenther Organization => OpenBSD
2013-02-08 22:46 philip-guenther Section => fmemopen
2013-02-08 22:46 philip-guenther Page Number => 867
2013-02-08 22:46 philip-guenther Line Number => 28775
2013-02-14 16:55 eblake Relationship added related to 0000396
2013-02-14 16:55 eblake Relationship added related to 0000456
2013-03-28 23:54 philip-guenther Note Added: 0001506
2014-01-30 04:06 eblake Relationship added related to 0000818


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