Proposed resolution:

This wording is relative to N3376.

1. Insert a new paragraph before [conversions.string] paragraph 16:

   wstring_convert(Codecvt *pcvt = new Codecvt);
   wstring_convert(Codecvt *pcvt, state_type state);
   wstring_convert(const byte_string& byte_err,
     const wide_string& wide_err = wide_string());
   

   -?- Requires: For the first and second constructors pcvt != nullptr.

   -16- Effects: The first constructor shall store pcvt in cvtptr and default values in cvtstate, byte_err_string, and wide_err_string. The second constructor shall store pcvt in cvtptr, state in cvtstate, and default values in byte_err_string and wide_err_string; moreover the stored state shall be retained between calls to from_bytes and to_bytes. The third constructor shall store new Codecvt in cvtptr, state_type() in cvtstate, byte_err in byte_err_string, and wide_err in wide_err_string.

2. Insert a new paragraph before [conversions.buffer] paragraph 10:

   wbuffer_convert(std::streambuf *bytebuf = 0,
     Codecvt *pcvt = new Codecvt, state_type state = state_type());
   

   -?- Requires: pcvt != nullptr.

   -10- Effects: The constructor constructs a stream buffer object, initializes bufptr to bytebuf, initializes cvtptr to pcvt, and initializes cvtstate to state.

[ 2013-04-20 Bristol ]

[ 2013-03-15 Issues Teleconference ]

Moved to Tentatively Ready.

See discussion following c++std-lib-32710.

It's not specified what happens if wstring_convert and wbuffer_convert objects are constructed with null Codecvt pointers.

Should the constructors have preconditions that the pointers are not null? If not, are conversions expected to fail, or is it undefined to attempt conversions if the pointers are null?

There are no observer functions to check whether objects were constructed with valid Codecvt pointers. If the types are made movable such observers would be necessary even if the constructors require non-null pointers (see also LWG 2176).