Proposed resolution:

Add after [ostream::sentry] p17:

~sentry();

-17- If (os.flags() & ios_base::unitbuf) is true, calls os.flush().

Throws: Nothing.

Rationale:

Solved by 835.

[ 2010 Pittsburgh: ]

Moved to NAD Editorial.

[ 2010-03-06 Martin updates wording. ]

[ 2009 Santa Cruz: ]

Move to Open. Our intent is to solve this issue with 835.

[ 2009-10-13 Daniel adds: ]

The proposed resolution of 835 is written to match the outcome of this issue.

[ 2009-07 Frankfurt ]

Move to Review. Add "Throws: nothing" to the specification of ostream::sentry::~sentry().

[ See 418 and 622 for related issues. ]

[ The contradiction is real. Clause 17 says destructors may never throw exceptions, and clause 27 specifies a destructor that does throw. In principle we might change either one. We're leaning toward changing clause 17: putting in an "unless otherwise specified" clause, and then putting in a footnote saying the sentry destructor is the only one that can throw. PJP suggests specifying that sentry::~sentry() should internally catch any exceptions it might cause. ]

17.4.4.8, p3 prohibits library dtors from throwing exceptions.

27.6.2.3, p4 says this about the ostream::sentry dtor:

    -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
        is true, calls os.flush().
    

27.6.2.6, p7 that describes ostream::flush() says:

    -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
        If that function returns ?-1 calls setstate(badbit) (which
        may throw ios_base::failure (27.4.4.3)).
    

That seems like a defect, since both pubsync() and setstate() can throw an exception.