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

2214. Clarify basic_ios::init call restrictions

Section: 31.5.4.2 [basic.ios.cons] Status: Open Submitter: Andrey Semashev Opened: 2012-11-09 Last modified: 2021-07-31

Priority: 4

View all other issues in [basic.ios.cons].

View all issues with Open status.

Discussion:

There is an ambiguity in how std::basic_ios::init method (31.5.4.2 [basic.ios.cons]) can be used in the derived class. The Standard only specify the state of the basic_ios object after the call completes. However, in basic_ios default constructor description (31.5.4.2 [basic.ios.cons]) there is this sentence:

Effects: Constructs an object of class basic_ios (31.5.2.8 [ios.base.cons]) leaving its member objects uninitialized. The object shall be initialized by calling basic_ios::init before its first use or before it is destroyed, whichever comes first; otherwise the behavior is undefined.

This restriction hints that basic_ios::init should be called exactly once before the object can be used or destroyed, because basic_ios::init may not know whether it was called before or not (i.e. whether its members are actually uninitialized or are initialized by the previous call to basic_ios::init). There is no such restriction in the basic_ios::init preconditions so it is not clear whether it is allowed to call basic_ios::init multiple times or not.

This problem has already affected publicly available implementations. For example, Microsoft Visual C++ STL introduces a memory leak if basic_ios::init is called multiple times, while GCC 4.7 and STLPort reinitialize the basic_ios object correctly without memory leak or any other undesired effects. There was a discussion of this issue on Boost developers mailing list, and there is a test case that reproduces the problem. The test case is actually a bug report for my Boost.Log library, which attempts to cache basic_ostream-derived objects internally to avoid expensive construction and destruction. My stream objects allowed resetting the stream buffer pointers the stream is attached to, without requiring to destroy and construct the stream.

My personal view of the problem and proposed resolution follows.

While apparently the intent of basic_ios::init is to provide a way to initialize basic_ios after default construction, I see no reason to forbid it from being called multiple times to reinitialize the stream. Furthermore, it is possible to implement a conforming basic_ios that does not have this restriction.

The quoted above section of the Standard that describes the effects of the default constructor is misleading. The Standard does not mandate any data members of basic_ios or ios_base (31.5.2 [ios.base]), which it derives from. This means that the implementation is allowed to use non-POD data members with default constructors that initialize the members with particular default values. For example, in the case of Microsoft Visual C++ STL the leaked memory is an std::locale instance that is dynamically allocated during basic_ios::init, a raw pointer to which is stored within ios_base. It is possible to store e.g. an unique_ptr instead of a raw pointer as a member of ios_base, the smart pointer will default initialize the underlying raw pointer on default construction and automatically destroy the allocated object upon being reset or destroyed, which would eliminate the leak and allow basic_ios::init to be called multiple times. This leads to conclusion that the default constructor of basic_ios cannot leave "its member objects uninitialized" but instead performs default initialization of the member objects, which would mean the same thing in case of POD types.

However, I feel that restricting ios_base and basic_ios members to non-POD types is not acceptable. Since multiple calls to basic_ios::init are not forbidden by the Standard, I propose to correct the basic_ios default constructor description so that it is allowed to destroy basic_ios object without calling basic_ios::init. This would imply that any raw members of basic_ios and ios_base should be initialized to values suitable for destruction (essentially, this means only initializing raw pointers to NULL). The new wording could look like this:

Effects: Constructs an object of class basic_ios (31.5.2.8 [ios.base.cons]) initializing its member objects to unspecified state, only suitable for basic_ios destruction. The object shall be initialized by calling basic_ios::init before its first use; otherwise the behavior is undefined.

This would remove the hint that basic_ios::init must be called exactly once. Also, this would remove the requirement for basic_ios::init to be called at all before the destruction. This is also an important issue because the derived stream constructor may throw an exception before it manages to call basic_ios::init (for example, if the streambuf constructor throws), and in this case the basic_ios destructor has undefined behavior.

To my mind, the described modification is sufficient to resolve the issue. But to emphasize the possibility to call basic_ios::init multiple times, a remark or a footnote for basic_ios::init postconditions could be added to explicitly state the semantics of calling it multiple times. The note could read as follows:

The function can be called multiple times during the object lifetime. Each subsequent call reinitializes the object to the described in postconditions initial state.

[2013-04-20, Bristol]

Alisdair: The current wording is unclear but the proposed resolution is wrong

Solution: Clarify that init must be called once and only once. Move then to review.

[2021-07-29 Tim comments]

The requirement that "init must be called once and only once" conflicts with the disposition of LWG 135⁽ⁱ⁾.

Proposed resolution:

This wording is relative to N3485.

1. Edit 31.5.4.2 [basic.ios.cons] as indicated:

   basic_ios();
   

   -2- Effects: Constructs an object of class basic_ios (31.5.2.8 [ios.base.cons]) leaving its member objects uninitializedinitializing its member objects to unspecified state, only suitable for basic_ios destruction. The object shall be initialized by calling basic_ios::init before its first use or before it is destroyed, whichever comes first; otherwise the behavior is undefined.

   void init(basic_streambuf<charT,traits>* sb);
   

   Postconditions: The postconditions of this function are indicated in Table 128.

   -?- Remarks: The function can be called multiple times during the object lifetime. Each subsequent call reinitializes the object to the described in postconditions initial state.