Proposed resolution:

This wording is relative to N4606.

1. Modify [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 [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.

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

[ 2018-08-23 Batavia Issues processing ]

Will be resolved by the adoption of P0487.

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

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

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

[ 2015-06, Telecon ]

VV: Request a paper to deprecate / remove anything

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.