Proposed resolution:

Add to the table "File open modes" in [filebuf.members]:

File open modes

ios_base Flag combination					stdio equivalent
binary	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"

[ 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.

In testing [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.