Section: 31.10.3.4 [filebuf.members] Status: CD1 Submitter: Thomas Plum Opened: 2006-09-26 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [filebuf.members].
View all issues with CD1 status.
Discussion:
In testing 31.10.3.4 [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, 7.19.5.3, 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 7.19.5.3 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.
Proposed resolution:
Add to the table "File open modes" in 31.10.3.4 [filebuf.members]:
File open modes ios_base
Flag combinationstdio
equivalentbinary
in
out
trunc
app
+
"w"
+
+
"a"
+
"a"
+
+
"w"
+
"r"
+
+
"r+"
+
+
+
"w+"
+
+
+
"a+"
+
+
"a+"
+
+
"wb"
+
+
+
"ab"
+
+
"ab"
+
+
+
"wb"
+
+
"rb"
+
+
+
"r+b"
+
+
+
+
"w+b"
+
+
+
+
"a+b"
+
+
+
"a+b"
[ Kona (2007) Added proposed wording and moved to Review. ]