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.

531. array forms of unformatted input functions

Section: 31.7.5.4 [istream.unformatted] Status: CD1 Submitter: Martin Sebor Opened: 2005-11-23 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [istream.unformatted].

View all issues with CD1 status.

Discussion:

The array forms of unformatted input functions don't seem to have well-defined semantics for zero-element arrays in a couple of cases. The affected ones (istream::get() and istream::getline()) are supposed to terminate when (n - 1) characters are stored, which obviously can never be true when (n == 0) holds to start with. See c++std-lib-16071.

Proposed resolution:

I suggest changing 27.6.1.3, p7 (istream::get()), bullet 1 to read:

• (n < 1) is true or (n - 1) characters are stored;

Change 27.6.1.3, p9:

If the function stores no characters, it calls setstate(failbit) (which may throw ios_base::failure (27.4.4.3)). In any case, if (n > 0) is true it then stores a null character into the next successive location of the array.

and similarly p17 (istream::getline()), bullet 3 to:

• (n < 1) is true or (n - 1) characters are stored (in which case the function calls setstate(failbit)).

In addition, to clarify that istream::getline() must not store the terminating NUL character unless the the array has non-zero size, Robert Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:

In any case, provided (n > 0) is true, it then stores a null character (using charT()) into the next successive location of the array.

[ post-Redmond: Pete noticed that the current resolution for get requires writing to out of bounds memory when n == 0. Martin provided fix. ]