Rationale:

Although the general philosophy of the input functions is that the argument should not be modified upon failure, getline historically added a terminating null unconditionally. Most implementations still do that. Earlier versions of the draft standard had language that made this an unambiguous requirement; those words were moved to a place where their context made them less clear. See Jerry Schwarz's message c++std-lib-7618.

Proposed resolution:

Add to 27.6.1.3, p1 after the sentence

"... If the sentry object returns true, when converted to a value of type bool, the function endeavors to obtain the requested input."

the following

"Otherwise, if the sentry constructor exits by throwing an exception or if the sentry object returns false, when converted to a value of type bool, the function returns without attempting to obtain any input. In either case the number of extracted characters is set to 0; unformatted input functions taking a character array of non-zero size as an argument shall also store a null character (using charT()) in the first location of the array."

basic_istream<>::get(), and basic_istream<>::getline(), are unclear with respect to the behavior and side-effects of the named functions in case of an error.

27.6.1.3, p1 states that "... If the sentry object returns true, when converted to a value of type bool, the function endeavors to obtain the requested input..." It is not clear from this (or the rest of the paragraph) what precisely the behavior should be when the sentry ctor exits by throwing an exception or when the sentry object returns false. In particular, what is the number of characters extracted that gcount() returns supposed to be?

27.6.1.3 p8 and p19 say about the effects of get() and getline(): "... In any case, it then stores a null character (using charT()) into the next successive location of the array." Is not clear whether this sentence applies if either of the conditions above holds (i.e., when sentry fails).