<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 220: ~ios_base() usage valid?</title>
<meta property="og:title" content="Issue 220: ~ios_base() usage valid?">
<meta property="og:description" content="C++ library issue. Status: TC1">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue220.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#TC1">TC1</a> status.</em></p>
<h3 id="220"><a href="lwg-defects.html#220">220</a>. ~ios_base() usage valid?</h3>
<p><b>Section:</b> 31.5.2.8 <a href="https://wg21.link/ios.base.cons">[ios.base.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Opened:</b> 2000-03-13 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#ios.base.cons">issues</a> in [ios.base.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
paragraph 2:</p>
<blockquote>
  <p>Effects: Destroys an object of class ios_base. Calls each registered
  callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
  time that any ios_base member function called from within fn has well defined
  results.</p>
</blockquote>
<p>But what is not clear is: If no callback functions were ever registered, does
it matter whether the ios_base members were ever initialized?</p>
<p>For instance, does this program have defined behavior:</p>
<blockquote>
  <pre>#include &lt;ios&gt;</pre>
  <pre>class D : public std::ios_base { };</pre>
  <pre>int main() { D d; }</pre>
</blockquote>
<p>It seems that registration of a callback function would surely affect the
state of an ios_base. That is, when you register a callback function with an
ios_base, the ios_base must record that fact somehow.</p>
<p>But if after construction the ios_base is in an indeterminate state, and that
state is not made determinate before the destructor is called, then how would
the destructor know if any callbacks had indeed been registered? And if the
number of callbacks that had been registered is indeterminate, then is not the
behavior of the destructor undefined?</p>
<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
it explicit that destruction before initialization results in undefined
behavior.</p>


<p id="res-220"><b>Proposed resolution:</b></p>
<p>Modify 27.4.2.7 paragraph 1 from</p>
<blockquote>
  <p>Effects: Each ios_base member has an indeterminate value after
  construction.</p>
</blockquote>
<p>to</p>
<blockquote>
  <p>Effects: Each ios_base member has an indeterminate value after
  construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations
  have taken place, the behavior is undefined.</p>
</blockquote>




</body>
</html>
