Section: 126.96.36.199 [filebuf.members] Status: CD1 Submitter: Thomas Plum Opened: 2006-09-26 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [filebuf.members].
View all issues with CD1 status.
In testing 188.8.131.52 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
and we expect the open to fail, because out|in|app is not listed in Table 92, and just before the table we see very specific words:
If mode is not some combination of flags shown in the table then the open fails.
But the corresponding table in the C standard, 184.108.40.206, provides two modes "a+" and "a+b", to which the C++ modes out|in|app and out|in|app|binary would presumably apply.
We would like to argue that the intent of Table 112 was to match the semantics of 220.127.116.11 and that the omission of "a+" and "a+b" was unintentional. (Otherwise there would be valid and useful behaviors available in C file I/O which are unavailable using C++, for no valid functional reason.)
We further request that the missing modes be explicitly restored to the WP, for inclusion in C++0x.
[ Martin adds: ]
...besides "a+" and "a+b" the C++ table is also missing a row for a lone app bit which in at least two current implementation as well as in Classic Iostreams corresponds to the C stdio "a" mode and has been traditionally documented as implying ios::out. Which means the table should also have a row for in|app meaning the same thing as "a+" already proposed in the issue.
Add to the table "File open modes" in 18.104.22.168 [filebuf.members]:
File open modes ios_base Flag combination stdio equivalent binary in out trunc app + "w" + + "a" + + "w" + "r" + + "r+" + + + "w+" + + "wb" + + + "ab" + + + "wb" + + "rb" + + + "r+b" + + + + "w+b"
[ Kona (2007) Added proposed wording and moved to Review. ]