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: 31.7.5.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 31.7.5.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 31.7.5.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.