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. ]