[ Post-Sydney: Howard provided a new proposed resolution. The old one didn't make sense because it proposed to fix this at the level of basic_filebuf, which doesn't have access to the stream's error state. Howard's proposed resolution fixes this at the level of the three fstream class template instead. ]

[ Kona: the LWG agrees this is a good idea. Post-Kona: Bill provided wording. He suggests having open, not close, clear the error flags. ]

Proposed resolution:

Change [ifstream.members], para. 3 from:

Calls rdbuf()->open(s,mode|in). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)].

to:

Calls rdbuf()->open(s,mode|in). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().

Change [ofstream.members], para. 3 from:

Calls rdbuf()->open(s,mode|out). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)).

to:

Calls rdbuf()->open(s,mode|out). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().

Change [fstream.members], para. 3 from:

Calls rdbuf()->open(s,mode), If that function returns a null pointer, calls setstate(failbit), (which may throw ios_base::failure). (lib.iostate.flags) )

to:

Calls rdbuf()->open(s,mode), If that function returns a null pointer, calls setstate(failbit), (which may throw ios_base::failure). (lib.iostate.flags) ), else calls clear().

A strict reading of [fstreams] shows that opening or closing a basic_[io]fstream does not affect the error bits. This means, for example, that if you read through a file up to EOF, and then close the stream and reopen it at the beginning of the file, the EOF bit in the stream's error state is still set. This is counterintuitive.

The LWG considered this issue once before, as issue 22, and put in a footnote to clarify that the strict reading was indeed correct. We did that because we believed the standard was unambiguous and consistent, and that we should not make architectural changes in a TC. Now that we're working on a new revision of the language, those considerations no longer apply.