|Anonymous | Login||2020-08-13 11:14 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Final Accepted Text|
|Summary||0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified|
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.
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.|
Another spot or two where glibc and the standard disagree:
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.
|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|