This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 2499. `operator>>(basic_istream&, CharT*)` makes it hard to avoid buffer overflows

Section: 29.7.4.3.3 [istream.extractors] Status: Resolved Submitter: Richard Smith Opened: 2015-05-08 Last modified: 2018-11-12

Priority: 2

View all other issues in [istream.extractors].

View all issues with Resolved status.

Discussion:

We removed `gets()` (due to an NB comment and C11 — bastion of backwards compatibility — doing the same). Should we remove this too?

Unlike `gets()`, there are legitimate uses:

>     char buffer[32];
>     char text[32] = // ...
>     ostream_for_buffer(text) >> buffer; // ok, can't overrun buffer

… but the risk from constructs like "`std::cin >> buffer`" seems to outweigh the benefit.

The issue had been discussed on the library reflector starting around c++std-lib-35541.

[2015-06, Telecon]

VV: Request a paper to deprecate / remove anything

[2015-10, Kona Saturday afternoon]

STL: This overload is evil and should probably die.

VV: I agree with that, even though I don't care.

STL: Say that we either remove it outright following the gets() rationale, or at least deprecate it.

Move to Open; needs a paper.

[2016-08, Chicago: Zhihao Yuan comments and provides wording]

Rationale:

1. I would like to keep some reasonable code working;

2. Reasonable code includes two cases:

   1. `width() > 0`, any pointer argument

   2. `width() >= 0`, array argument

3. For a), banning bad code will become a silent behavior change at runtime; for b), it breaks at compile time.

I propose to replace these signatures with references to arrays. An implementation may want to ship the old instantiatations in the binary without exposing the old signatures.

[2016-08, Chicago]

Tues PM: General agreement on deprecating the unsafe call, but no consensus for the P/R.

General feeling that implementation experience would be useful.

[2018-08-23 Batavia Issues processing]

Will be resolved by the adoption of P0487.

[2018-11-11 Resolved by P0487R1, adopted in San Diego.]

Proposed resolution:

This wording is relative to N4606.

1. Modify 29.7.4.3.3 [istream.extractors] as indicated:

   >     template<class charT, class traits, size_t N>
   >       basic_istream<charT, traits>& operator>>(basic_istream<charT, traits>& in,
   >                                                charT* scharT (&s)[N]);
   >     template<class traits, size_t N>
   >       basic_istream<char, traits>& operator>>(basic_istream<char, traits>& in,
   >                                               unsigned char* sunsigned char (&s)[N]);
   >     template<class traits, size_t N>
   >       basic_istream<char, traits>& operator>>(basic_istream<char, traits>& in,
   >                                               signed char* ssigned char (&s)[N]);

   > > -7- Effects: Behaves like a formatted input member (as described in 29.7.4.3.1 [istream.formatted.reqmts]) of `in`. After a `sentry` object is constructed, `operator>>` extracts characters and stores them into successive locations of an array whose first element is designated by `s`. If `width()` is greater than zero, `n` is `width()min(size_t(width()), N)`. Otherwise `n` is the number of elements of the largest array of `char_type` that can store a terminating `charT()``N`. `n` is the maximum number of characters stored.