This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 188.8.131.52 [istream.unformatted] Status: CD1 Submitter: Martin Sebor Opened: 2000-05-15 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [istream.unformatted].
View all issues with CD1 status.
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.
184.108.40.206, 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?
220.127.116.11 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).
Add to 18.104.22.168, 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."
"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."
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.