The resolution to issue 581

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2578.html#581

requires that basic_ostream::flush creates a sentry object to verify
the stream state.

However, for streams with the unit_buf flag set, like std::err, the
destructor of the sentry object will again call flush(). This seems to
create an infinite recursion for

std::cerr << std::flush;

or even

std::cerr << "Some message"  << std::endl;

Have I missed something here?

Bo Persson

"Behaves as an unformatted output function (as described in
27.6.2.6.1,
paragraph 1).[..]"

because 27.6.2.6.1/p.1 describes the semantic of *formatted*
output functions.

Greetings from Bremen,

Daniel Krügler

   If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
   is true, calls os.rdbuf()->pubsync().

to avoid this. Let me fix it along with the similar problem
with the tied stream.

Let me add three related questions, which came to me while
I was searching of references to flush:

1) N2588, [istream::sentry]/2, describes effects in terms of
flush on the result of is.tie(). Wouldn't it make sense to
refer here to is.tie()->rdbuf()->pubsync() as well? All other
effects of this c'tor are already based on rdbuf() functions
(of is).

2) I think that footnote 321, N2588, needs also to be adapted.

3) I have a question regarding [ios::Init]/4: The effects clause
of ~Init() says:

"Destroys an object of class Init. The function subtracts one from
the value stored in init_cnt and, if the resulting stored value is
one, calls cout.flush(), cerr.flush(), clog.flush(), wcout.flush(),
wcerr.flush(), wclog.flush()."

But because flush can (indirectly) throw a ios_base::failure,
I see two problems:

1) Does the standard need to rule this exception, although it
happens after program execution ([iostream.objects]/2)?

2) Actually worse seems to me that the standard seems not to
provide guarantees that such an intermediate throw does not
influence the outstanding flushs. What I mean is the following:
Consider that

cout.flush(), cerr.flush(),  ..

are called and cout.flush() throws. Will cerr.flush() and
all remaining flush()'s still be called? I would like to
hear such statement, but during a short survey I couldn't
find anything.

[Please note that these "issues" of (3) are not new, but
I just stumbled across them]

Greetings from Bremen,

Daniel Krügler