diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 08e6c3be93e..a9ed643112c 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,7 @@
+2006-04-23  Paolo Carlini  <pcarlini@suse.de>
+
+	* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 42.
+
 2006-04-19  Paolo Carlini  <pcarlini@suse.de>
 
 	PR libstdc++/26424
diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html
index bd2346fc836..3e279f4d93d 100644
--- a/libstdc++-v3/docs/html/ext/lwg-active.html
+++ b/libstdc++-v3/docs/html/ext/lwg-active.html
@@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head>
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N1949=06-0019</td>
+<td align="left">N2000=06-0070</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2006-02-24</td>
+<td align="left">2006-04-21</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head>
 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Active Issues List (Revision R41)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R42)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
   <ul>
@@ -91,6 +91,15 @@ del {background-color:#FFFFA0}</style></head>
   directory as the issues list files.  </p>
 <h2>Revision History</h2>
 <ul>
+<li>R42: 
+2006-04-21 post-Berlin mailing.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#549">549</a> to Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review.
+</li>
 <li>R41: 
 2006-02-24 pre-Berlin mailing.
 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>.
@@ -105,9 +114,9 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active
 2005-10-14 post-Mont Tremblant mailing.
 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 </li>
@@ -142,7 +151,7 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#
 <li>R31: 
 2004-07 mid-term mailing: reflects new proposed resolutions and
 new issues received after the post-Sydney mailing.  Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>.
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 </li>
 <li>R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
@@ -179,7 +188,7 @@ Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/
 Moved issues in the TC to TC status.
 </li>
 <li>R22: 
-Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
+Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
 </li>
 <li>R21: 
 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
@@ -377,6 +386,12 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64
   <b>Proposed Resolution</b> is now available for review on an issue
   for which the LWG previously reached informal consensus.</p>
 
+  <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
+  been reviewed online, but not in a meeting, and some support has been formed
+  for the proposed resolution.  Tentatively Ready issues may be moved to Ready
+  and forwarded to full committee within the same meeting.  Unlike Ready issues
+  they will be reviewed in subcommittee prior to forwarding to full committee.</p>
+
   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
   that the issue is a defect in the Standard, the <b>Proposed
   Resolution</b> is correct, and the issue is ready to forward to the
@@ -706,69 +721,6 @@ suggests so the LWG can decide between the two options.]</i></p>
 feedback from Lillehammer with more information regarding performance.
 ]</i></p>
 
-<hr>
-<a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
-<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
-of <tt>vector::insert</tt>:</p>
-
-   <blockquote>
-   Complexity: If first and last are forward iterators, bidirectional
-   iterators, or random access iterators, the complexity is linear in
-   the number of elements in the range [first, last) plus the distance
-   to the end of the vector. If they are input iterators, the complexity
-   is proportional to the number of elements in the range [first, last)
-   times the distance to the end of the vector.
-   </blockquote>
-
-<p>First, this fails to address the non-iterator forms of
-<tt>insert</tt>.</p>
-
-<p>Second, the complexity for input iterators misses an edge case --
-it requires that an arbitrary number of elements can be added at
-the end of a <tt>vector</tt> in constant time.</p>
-
-<p>I looked to see if <tt>deque</tt> had a similar problem, and was
-surprised to find that <tt>deque</tt> places no requirement on the
-complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
-paragraph 3):</p>
-
-   <blockquote>
-   Complexity: In the worst case, inserting a single element into a
-   deque takes time linear in the minimum of the distance from the
-   insertion point to the beginning of the deque and the distance
-   from the insertion point to the end of the deque. Inserting a
-   single element either at the beginning or end of a deque always
-   takes constant time and causes a single call to the copy constructor
-   of T.
-   </blockquote>
-<p><b>Proposed resolution:</b></p>
-
-<p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p>
-   <blockquote>
-   Complexity: The complexity is linear in the number of elements 
-   inserted plus the distance to the end of the vector.
-   </blockquote>
-
-   <p><i>[For input iterators, one may achieve this complexity by first
-   inserting at the end of the <tt>vector</tt>, and then using
-   <tt>rotate</tt>.]</i></p>
-
-<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p>
-
-   <blockquote>
-   Complexity: The complexity is linear in the number of elements 
-   inserted plus the shorter of the distances to the beginning and
-   end of the deque.  Inserting a single element at either the
-   beginning or the end of a deque causes a single call to the copy
-   constructor of T.
-   </blockquote>
-
-<p><b>Rationale:</b></p>
-<p>This is a real defect, and proposed resolution fixes it: some
-  complexities aren't specified that should be.  This proposed
-  resolution does constrain deque implementations (it rules out the
-  most naive possible implementations), but the LWG doesn't see a
-  reason to permit that implementation.</p>
 <hr>
 <a name="254"><h3>254.&nbsp;Exception types in clause 19 are constructed from <tt>std::string</tt>
 </h3></a><p><b>Section:</b>&nbsp;19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Aug 2000</p>
@@ -981,7 +933,7 @@ the second line from the bottom in table 32 already implies the
 desired property.  This issue should be considered in light of
 other issues related to allocator instances.]</i></p>
 <hr>
-<a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
+<a name="290"></a><h3><a name="290">290.&nbsp;Requirements to for_each and its function object</a></h3><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
 <p>The specification of the for_each algorithm does not have a
 "Requires" section, which means that there are no
 restrictions imposed on the function object whatsoever. In essence it
@@ -1013,54 +965,6 @@ algorithm does not say so.
   saying that user code operating on a range may not invalidate
   iterators unless otherwise specified.  Bill will provide wording.]</i></p>
 
-<hr>
-<a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
-<p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
-translation unit that includes a header shall not contain any macros
-that define names declared in that header." As I read this, it
-would mean that the following program is legal:</p>
-
-<pre>  #define npos 3.14
-  #include &lt;sstream&gt;
-</pre>
-
-<p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
-in &lt;string&gt;, and it is hard to imagine an implementation in
-which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
-
-<p>I think that this phrase was probably formulated before it was
-decided that a standard header may freely include other standard
-headers.  The phrase would be perfectly appropriate for C, for
-example.  In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
-it isn't stringent enough.</p>
-<p><b>Proposed resolution:</b></p>
-<p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p>
-<blockquote>
-     <p>Each name defined as a macro in a header is reserved to the
-     implementation for any use if the translation unit includes
-     the header.168)</p>
-
-     <p>A translation unit that includes a header shall not contain any
-     macros that define names declared or defined in that header. Nor shall
-     such a translation unit define macros for names lexically
-     identical to keywords.</p>
-
-     <p>168) It is not permissible to remove a library macro definition by
-     using the #undef directive.</p>
-</blockquote>
-
-<p>with the wording:</p>
-
-<blockquote>
-     <p>A translation unit that includes a standard library header shall not
-     #define or #undef names declared in any standard library header.</p>
-
-     <p>A translation unit shall not #define or #undef names lexically
-     identical to keywords.</p>
-</blockquote>
-
-<p><i>[Lillehammer: Beman provided new wording]</i></p>
-
 <hr>
 <a name="299"><h3>299.&nbsp;Incorrect return types for iterator dereference</h3></a><p><b>Section:</b>&nbsp;24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;22 Jan 2001</p>
 <p>
@@ -1165,7 +1069,7 @@ with a return type of convertible to <tt>T</tt> and operational semantics of
   iterator redesign]</i></p>
 
 <hr>
-<a name="309"></a><h3><a name="309">309.&nbsp;Does sentry catch exceptions?</a></h3><p><b>Section:</b>&nbsp;27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;19 Mar 2001</p>
+<a name="309"><h3>309.&nbsp;Does sentry catch exceptions?</h3></a><p><b>Section:</b>&nbsp;27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;19 Mar 2001</p>
 <p>
 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
 (27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream&lt;&gt;::sentry
@@ -1507,262 +1411,6 @@ In case of failure, the function calls <tt>setstate(failbit)</tt>
   or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
   than <tt>good()</tt>, satisfies this goal.</p>
 <hr>
-<a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
-<p>
-The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
-the construction of an unsafe binding between incompatible pointer
-types. For example, given a function whose first parameter type is
-'pointer to T', it's possible without error to bind an argument of
-type 'pointer to U' when U does not derive from T:
-</p>
-<pre>   foo(T*, int);
-
-   struct T {};
-   struct U {};
-
-   U u;
-
-   int* p;
-   int* q;
-
-   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
-</pre>
-
-<p>
-The definition of bind1st() includes a functional-style conversion to
-map its argument to the expected argument type of the bound function
-(see below):
-</p>
-<pre>  typename Operation::first_argument_type(x)
-</pre>
-
-<p>
-A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
-semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
-as a reinterpret_cast, thus masking the error.
-</p>
-
-<p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1:
-  "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
-  favor of <tt>std::tr1::bind</tt>."</p>
-
-<p>(Notes to editor: (1) when and if tr1::bind is incorporated into
-  the standard, "std::tr1::bind" should be changed to "std::bind". (2)
-  20.3.6 should probably be moved to Annex D.</p>
-<p><b>Rationale:</b></p>
-<p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
-  superior solution.  It solves this problem and others.</p>
-<hr>
-<a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
-<p>
-Is it safe to use standard iostream objects from constructors of
-static objects?  Are standard iostream objects constructed and are
-their associations established at that time?
-</p>
-
-<p>Surpisingly enough, Standard does NOT require that.</p>
-
-<p>
-27.3/2 [lib.iostream.objects] guarantees that standard iostream
-objects are constructed and their associations are established before
-the body of main() begins execution.  It also refers to ios_base::Init
-class as the panacea for constructors of static objects.
-</p>
-
-<p>
-However, there's nothing in 27.3 [lib.iostream.objects],
-in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
-that would require implementations to allow access to standard
-iostream objects from constructors of static objects.
-</p>
-
-<p>Details:</p>
-
-<p>Core text refers to some magic object ios_base::Init, which will
-be discussed below:</p>
-
-<blockquote>
-    "The [standard iostream] objects are constructed, and their
-    associations are established at some time prior to or during
-    first time an object of class basic_ios&lt;charT,traits&gt;::Init
-    is constructed, and in any case before the body of main
-    begins execution." (27.3/2 [lib.iostream.objects])
-</blockquote>
-
-<p>
-The first <i>non-normative</i> footnote encourages implementations
-to initialize standard iostream objects earlier than required.
-</p>
-
-<p>However, the second <i>non-normative</i> footnote makes an explicit
-and unsupported claim:</p>
-
-<blockquote>
-  "Constructors and destructors for static objects can access these
-  [standard iostream] objects to read input from stdin or write output
-  to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
-</blockquote>
-
-<p>
-The only bit of magic is related to that ios_base::Init class.  AFAIK,
-the rationale behind ios_base::Init was to bring an instance of this
-class to each translation unit which #included &lt;iostream&gt; or
-related header.  Such an inclusion would support the claim of footnote
-quoted above, because in order to use some standard iostream object it
-is necessary to #include &lt;iostream&gt;.
-</p>
-
-<p>
-However, while Standard explicitly describes ios_base::Init as
-an appropriate class for doing the trick, I failed to found a
-mention of an _instance_ of ios_base::Init in Standard.
-</p>
-<p><b>Proposed resolution:</b></p>
-
-<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
-of the paragraph, the following two sentences:</p>
-
-<blockquote>
-If a translation unit includes &lt;iostream&gt;, or explicitly
-constructs an ios_base::Init object, these stream objects shall
-be constructed before dynamic initialization of non-local
-objects defined later in that translation unit, and these stream
-objects shall be destroyed after the destruction of dynamically
-initialized non-local objects defined later in that translation unit.
-</blockquote>
-
-<p><i>[Lillehammer: Matt provided wording.]</i></p>
-<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
-<p><b>Rationale:</b></p>
-<p>
-The original proposed resolution unconditionally required
-implementations to define an ios_base::Init object of some
-implementation-defined name in the header &lt;iostream&gt;. That's an
-overspecification. First, defining the object may be unnecessary
-and even detrimental to performance if an implementation can
-guarantee that the 8 standard iostream objects will be initialized
-before any other user-defined object in a program. Second, there
-is no need to require implementations to document the name of the
-object.</p>
-
-<p>
-The new proposed resolution gives users guidance on what they need to
-do to ensure that stream objects are constructed during startup.</p>
-<hr>
-<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
-<p>
-The requirements for multiset and multimap containers (23.1
-[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
-23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
-the stability of the required (mutating) member functions. It appears
-the standard allows these functions to reorder equivalent elements of
-the container at will, yet the pervasive red-black tree implementation
-appears to provide stable behaviour.
-</p>
-
-<p>This is of most concern when considering the behaviour of erase().
-A stability requirement would guarantee the correct working of the
-following 'idiom' that removes elements based on a certain predicate
-function.
-</p>
-
-<pre>  multimap&lt;int, int&gt; m;
-  multimap&lt;int, int&gt;::iterator i = m.begin();
-  while (i != m.end()) {
-      if (pred(i))
-          m.erase (i++);
-      else
-          ++i;
-  }
-</pre>
-
-<p>
-Although clause 23.1.2/8 guarantees that i remains a valid iterator
-througout this loop, absence of the stability requirement could
-potentially result in elements being skipped. This would make
-this code incorrect, and, furthermore, means that there is no way
-of erasing these elements without iterating first over the entire
-container, and second over the elements to be erased. This would
-be unfortunate, and have a negative impact on both performance and
-code simplicity.
-</p>
-
-<p>
-If the stability requirement is intended, it should be made explicit
-(probably through an extra paragraph in clause 23.1.2).
-</p>
-<p>
-If it turns out stability cannot be guaranteed, i'd argue that a
-remark or footnote is called for (also somewhere in clause 23.1.2) to
-warn against relying on stable behaviour (as demonstrated by the code
-above).  If most implementations will display stable behaviour, any
-problems emerging on an implementation without stable behaviour will
-be hard to track down by users. This would also make the need for an
-erase_if() member function that much greater.
-</p>
-
-<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4: 
-"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
-  are <i>stable</i>: they preserve the relative ordering of equivalent
-  elements.</p> 
-
-<p><i>[Lillehammer: Matt provided wording]</i></p>
-<p><i>[Joe Gottman points out that the provided wording does not address
-multimap and multiset.  N1780 also addresses this issue and suggests
-wording.]</i></p>
-
-<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees that this guarantee is necessary for common user
-  idioms to work, and that all existing implementations provide this
-  property.  Note that this resolution guarantees stability for
-  multimap and multiset, not for all associative containers in
-  general.</p>
-
-<hr>
-<a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
-<p>
-In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
-the four conditions should be mutually exclusive, but they are not.
-The first two cases, as written, are subcases of the third.</p>
-
-<p>
-As written, it is unclear what should be the result if cases 1 and 2
-are both true, but case 3 is false.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Rewrite these conditions as:</p>
-<blockquote>
-<p>
-  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
-</p>
-
-<p>
-  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
-</p>
-
-<p>
-  (which &amp; (ios_base::in|ios_base::out)) == 
-(ios_base::in|ios_base::out)
-   and way == either ios_base::beg or ios_base::end
-</p>
-
-<p>Otherwise</p>
-</blockquote>
-
-<p><b>Rationale:</b></p>
-<p>It's clear what we wanted to say, we just failed to say it.  This
-  fixes it.</p>
-<hr>
 <a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;30 Aug  2002</p>
 <p>
 It seems that the descriptions of codecvt do_in() and do_out() leave
@@ -1874,64 +1522,6 @@ partial can only occur if (from_next != from_end)?
   seem sufficient for C++0x. Bill supports general N-to-M conversions;
   we need to make sure Martin and Howard agree.]</i></p>
 
-<hr>
-<a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
-<p>
-Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
-states that at most 2 * log(last - first) + 1
-comparisons are allowed for equal_range.
-</p>
-
-<p>It is not possible to implement equal_range with these constraints.</p>
-
-<p>In a range of one element as in:</p>
-<pre>    int x = 1;
-    equal_range(&amp;x, &amp;x + 1, 1)
-</pre>
-
-<p>it is easy to see that at least 2 comparison operations are needed.</p>
-
-<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
-
-<p>I have checked a few libraries and they all use the same (nonconforming)
-algorithm for equal_range that has a complexity of</p>
-<pre>     2* log(distance(first, last)) + 2.
-</pre>
-<p>I guess this is the algorithm that the standard assumes for equal_range.</p>
-
-<p>
-It is easy to see that 2 * log(distance) + 2 comparisons are enough
-since equal range can be implemented with lower_bound and upper_bound
-(both log(distance) + 1).
-</p>
-
-<p>
-I think it is better to require something like 2log(distance) + O(1)  (or
-even logarithmic as multiset::equal_range).
-Then an implementation has more room to optimize for certain cases (e.g.
-have log(distance) characteristics when at most match is found in the range
-but 2log(distance) + 4 for the worst case).
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt>
-to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-
-<p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt>
-to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-
-<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt>
-to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-
-<p><i>[Matt provided wording]</i></p>
-<p><b>Rationale:</b></p>
-<p>The LWG considered just saying <i>O</i>(log n) for all three, but
-Ê decided that threw away too much valuable information.Ê The fact
-Ê that lower_bound is twice as fast as equal_range is important.
-Ê However, it's better to allow an arbitrary additive constant than to
-Ê specify an exact count.Ê An exact count would have to
-Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to
-Ê get this wrong, and don't provide any substantial value for users.</p>
 <hr>
 <a name="385"><h3>385.&nbsp;Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
 <p>
@@ -2257,7 +1847,7 @@ is <i>zero</i>. Otherwise, the element has the value 1.</p>
   fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
 
 <hr>
-<a name="397"></a><h3><a name="397">397.&nbsp;ostream::sentry dtor throws exceptions</a></h3><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
+<a name="397"><h3>397.&nbsp;ostream::sentry dtor throws exceptions</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
     <p>
 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
     </p>
@@ -2971,7 +2561,7 @@ library class templates. We need to consult with CWG to make sure we
 use the right wording.]</i></p>
 
 <hr>
-<a name="423"><h3>423.&nbsp;effects of negative streamsize in iostreams</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
+<a name="423"></a><h3><a name="423">423.&nbsp;effects of negative streamsize in iostreams</a></h3><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
 
 <p>
 A third party test suite tries to exercise istream::ignore(N) with
@@ -3916,131 +3506,6 @@ facet's virtuals may never call each other. We might want to do that
 in clause 27 too, for that matter. A review is necessary.  Bill will
 provide wording.</p>
 <hr>
-<a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
-<p>
-It is not clear whether the function object passed to for_each is allowed to
-modify the elements of the sequence being iterated over.
-</p>
-
-<p>
-for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
-Non-modifying sequence operations". 'Non-modifying sequence operation' is
-never defined.
-</p>
-
-<p>
-25(5) says: "If an algorithm's Effects section says that a value pointed to
-by any iterator passed as an argument is modified, then that algorithm has
-an additional type requirement: The type of that argument shall satisfy the
-requirements of a mutable iterator (24.1)."
-</p>
-
-<p>for_each's Effects section does not mention whether arguments can be
-modified:</p>
-
-<blockquote>
-  "Effects: Applies f to the result of dereferencing every iterator in the
-   range [first, last), starting from first and proceeding to last - 1."
-</blockquote>
-
-<p>
-Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
-the sense that neither the algorithms themselves nor the function objects
-passed to the algorithms may modify the sequences or elements in any way.
-This DR affects only for_each.
-</p>
-
-<p>
-We suspect that for_each's classification in "non-modifying sequence
-operations" means that the algorithm itself does not inherently modify the
-sequence or the elements in the sequence, but that the function object
-passed to it may modify the elements it operates on. 
-</p>
-
-<p>
-The original STL document by Stepanov and Lee explicitly prohibited the
-function object from modifying its argument.
-The "obvious" implementation of for_each found in several standard library 
-implementations, however, does not impose this restriction.
-As a result, we suspect that the use of for_each with function objects that modify
-their arguments is wide-spread. 
-If the restriction was reinstated, all such code would become non-conforming.
-Further, none of the other algorithms in the Standard
-could serve the purpose of for_each (transform does not guarantee the order in
-which its function object is called). 
-</p>
-
-<p>
-We suggest that the standard be clarified to explicitly allow the function object 
-passed to for_each modify its argument.</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If
-the type of 'first' satisfies the requirements of a mutable iterator,
-'f' may apply nonconstant functions through the dereferenced iterators
-passed to it.
-</p>
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that nothing in the standard prohibits function
-  objects that modify the sequence elements. The problem is that
-  for_each is in a secion entitled "nonmutating algorithms", and the
-  title may be confusing.  A nonnormative note should clarify that.</p>
-<hr>
-<a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
-<p>
-The Forward Iterator requirements table contains the following:
-</p>
-<pre> expression  return type         operational  precondition
-                                  semantics
-  ==========  ==================  ===========  ==========================
-  a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
-              otherwise const U&amp;
-
-  r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
-</pre>
-
-<p>The second line may be unnecessary.  Paragraph 11 of
-  [lib.iterator.requirements] says:
-</p>
-
-<blockquote>
-   In the following sections, a and b denote values of type const X, n
-   denotes a value of the difference type Distance, u, tmp, and m
-   denote identifiers, r denotes a value of X&amp;, t denotes a value of
-   value type T, o denotes a value of some type that is writable to
-   the output iterator.
-</blockquote>
-
-<p>
-Because operators can be overloaded on an iterator's const-ness, the
-current requirements allow iterators to make many of the operations
-specified using the identifiers a and b invalid for non-const
-iterators.</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
-<p><b>Proposed resolution:</b></p>
-
-<p>Remove the "r-&gt;m" line from the Forward Iterator requirements
-table. Change</p>
-<blockquote>
-    "const X"
-</blockquote>
-
-<p> to </p>
-
-<blockquote>
-    "X or const X" 
-</blockquote>
-
-<p>in paragraph 11 of [lib.iterator.requirements].</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-This is a defect because it constrains an lvalue to returning a modifiable lvalue.
-</p>
-<hr>
 <a name="479"><h3>479.&nbsp;Container requirements and placement new</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;1 Aug 2004</p>
 <p>Nothing in the standard appears to make this program ill-formed:</p>
 
@@ -4410,118 +3875,6 @@ about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
 not quite broad enough, because there are some arithmetic expressions
 it doesn't cover. Bill will provide wording.]</i></p>
 
-<hr>
-<a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
-<p>It appears that there are no requirements specified for many of the
-template parameters in clause 22. It looks like this issue has never
-come up, except perhaps for Facet.</p>
-
-<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
-either, which is the wording that allows requirements on template
-parameters to be identified by name.</p>
-
-<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
-changed to cover clause 22. A better change, which will cover us in
-the future, would be to say that it applies to all the library
-clauses. Then if a template gets added to any library clause we are
-covered.</p>
-
-<p>charT, InputIterator, and other names with requirements defined
-elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
-But there are a few template arguments names which I don't think have
-requirements given elsewhere:</p>
-
-<ul>
-<li>internT and externT.  The fix is to add wording saying that internT
-and externT must meet the same requirements as template arguments
-named charT.</li>
-
-<li>stateT.  I'm not sure about this one. There already is some wording,
-but it seems a bit vague.</li>
-
-<li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
-rename "Intl" to "International". The name is important because other
-text identifies the requirements for the name International but not
-for Intl.</li>
-</ul>
-<p><b>Proposed resolution:</b></p>
-<p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p>
-<blockquote>
-The Requirements subclauses may describe names that are used to
-specify constraints on template arguments.153) These names are used in
-clauses 20, 23, 25, and 26 to describe the types that may be supplied
-as arguments by a C++ program when instantiating template components
-from the library. 
-</blockquote>
-<p>to:</p>
-<blockquote>
-The Requirements subclauses may describe names that are used to
-specify constraints on template arguments.153) These names are used in
-library clauses to describe the types that may be supplied as
-arguments by a C++ program when instantiating template components from
-the library.
-</blockquote>
-
-<p>In the front matter of class 22, locales, add:</p>
-<blockquote>
-Template parameter types internT and externT shall meet the
-requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>).
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>
- Again, a blanket clause isn't blanket enough. Also, we've got a
- couple of names that we don't have blanket requirement statements
- for. The only issue is what to do about stateT. This wording is
- thin, but probably adequate.</p>
-<hr>
-<a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
-
-<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
-
-<blockquote>
-<p>static const bool traps;<br>
--59- true if trapping is implemented for the type.204)
-<br>
-Footnote 204: Required by LIA-1.
-</p>
-</blockquote>
-
-<p>It's not clear what is meant by "is implemented" here.</p>
-
-<p>
-In the context of floating point numbers it seems reasonable to expect
-to be able to use traps to determine whether a program can "safely" use
-infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
-without causing a trap (i.e., on UNIX without having to worry about
-getting a signal). When traps is true, I would expect any of the
-operations in section 7 of IEEE 754 to cause a trap (and my program
-to get a SIGFPE). So, for example, on Alpha, I would expect traps
-to be true by default (unless I compiled my program with the -ieee
-option), false by default on most other popular architectures,
-including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
-traps to be explicitly enabled by the program.
-</p>
-
-<p>
-Another possible interpretation of p59 is that traps should be true
-on any implementation that supports traps regardless of whether they
-are enabled by default or not. I don't think such an interpretation
-makes the traps member very useful, even though that is how traps is
-implemented on several platforms. It is also the only way to implement
-traps on platforms that allow programs to enable and disable trapping
-at runtime.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change p59 to read:</p>
-<blockquote>True if, at program startup, there exists a value of the type that
-  would cause an arithmetic operation using that value to trap.</blockquote>
-<p><b>Rationale:</b></p>
-<p>
- Real issue, since trapping can be turned on and off. Unclear what a
- static query can say about a dynamic issue. The real advice we should
- give users is to use cfenv for these sorts of queries. But this new
- proposed resolution is at least consistent and slightly better than
- nothing.</p>
 <hr>
 <a name="498"><h3>498.&nbsp;Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b>&nbsp;25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Sean Parent, Joe Gottman&nbsp; <b>Date:</b>&nbsp;4 May 2005</p>
 <p>
@@ -4579,117 +3932,7 @@ by next meeting. Sean provided further rationale by post-meeting
 mailing.]</i></p>
 
 <hr>
-<a name="499"><h3>499.&nbsp;Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b>&nbsp;25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Prateek Karandikar&nbsp; <b>Date:</b>&nbsp;12 Apr 2005</p>
-<blockquote>
-<p>
-17.3.1.1 Summary</p>
-
-<p>
-1 The Summary provides a synopsis of the category, and introduces the 
-first-level subclauses. Each subclause also provides a summary, listing 
-the headers specified in the subclause and the library entities 
-provided in each header. 
-</p>
-<p>
-2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, 
-other paragraphs are normative.
-</p>
-</blockquote> 
-
-<p>So this means that a "Notes" paragraph wouldn't be normative. </p>
-
-<blockquote>
-<p>
-25.3.1.2 stable_sort
-</p>
-<pre>template&lt;class RandomAccessIterator&gt; 
-void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); 
-
-template&lt;class RandomAccessIterator, class Compare&gt; 
-void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
-</pre>
-<p>
-1 Effects: Sorts the elements in the range [first, last).
-</p>
-<p>
-2 Complexity: It does at most N(log N)^2 (where N == last - first) 
-comparisons; if enough extra memory is available, it is N log N.
-</p>
-<p>
-3 Notes: Stable: the relative order of the equivalent elements is 
-preserved. 
-</p>
-</blockquote> 
-
-<p>
-The Notes para is informative, and nowhere else is stability mentioned above. 
-</p>
-
-<p>
-Also, I just searched for the word "stable" in my copy of the Standard. 
-and the phrase "Notes: Stable: the relative order of the elements..." 
-is repeated several times in the Standard library clauses for 
-describing various functions. How is it that stability is talked about 
-in the informative paragraph? Or am I missing something obvious? 
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-<hr>
-<a name="501"><h3>501.&nbsp;Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b>&nbsp;20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Me &lt;anti_spam_email2003@yahoo.com&gt;&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p>
-<blockquote>
-"For templates greater, less, greater_equal, and less_equal,
-the specializations for any pointer type yield a total order, even if
-the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
-</blockquote>
-
-<p>
-The standard should do much better than guarantee that these provide a
-total order, it should guarantee that it can be used to test if memory
-overlaps, i.e. write a portable memmove. You can imagine a platform
-where the built-in operators use a uint32_t comparison (this tests for
-overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
-defined to use a int32_t comparison. On this platform, if you use
-std::less with the intent of making a portable memmove, comparison on
-an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
-incorrect results.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a footnote to 20.3.3/8 saying:
-</p>
-
-<blockquote>
-Given a p1 and p2 such that p1 points to N objects of type T and p2
-points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
-less returns the same value when comparing all pointers in [p1,p1+N) to
-all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
-such that less returns the same value when comparing all pointers in
-[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
-comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
-For the sake of completeness, the null pointer value (4.10) for T is
-considered to be an array of 1 object that doesn't overlap with any
-non-null pointer to T. less_equal, greater, greater_equal, equal_to,
-and not_equal_to give the expected results based on the total ordering
-semantics of less. For T of void, treat it as having similar semantics
-as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
-void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
-char*)(cv void*)a, (cv char*)(cv void*)b).
-</blockquote>
-
-<p>
-I'm also thinking there should be a footnote to 20.3.3/1 saying that if
-A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
-as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
-be problematic if there is some really funky operator overloading going
-on that does different things based on cv (that should be undefined
-behavior if somebody does that though). This at least should be
-guaranteed for all POD types (especially pointers) that use the
-built-in comparison operators.
-</p>
-
-<hr>
-<a name="502"><h3>502.&nbsp;Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Christopher Conrade Zseleghovski&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p>
+<a name="502"><h3>502.&nbsp;Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Christopher Conrade Zseleghovski&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p>
 <p>
 Motivation:
 </p>
@@ -4714,8 +3957,14 @@ sequence of input characters and not on how they are accessed.
 For a *_put facet, it means that the sequence of characters output depends 
 only on the value to be formatted and not of how the characters are stored.
 </p>
+
+<p><i>[
+Berlin:  Moved to Open, Need to clean up this area to make it clear
+locales don't have to contain open ended sets of facets. Jack, Howard,
+Bill.
+]</i></p>
 <hr>
-<a name="503"><h3>503.&nbsp;more on locales</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;20 Jun 2005</p>
+<a name="503"><h3>503.&nbsp;more on locales</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;20 Jun 2005</p>
 <p>
 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
 51" to refer to the facet *objects* associated with a locale. And we
@@ -4810,8 +4059,11 @@ facet, but several also need to use a codecvt facet and we don't say so.
 <p><b>Proposed resolution:</b></p>
 <p>
 </p>
+<p><i>[
+Berlin: Bill to provide wording.
+]</i></p>
 <hr>
-<a name="504"><h3>504.&nbsp;Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<a name="504"><h3>504.&nbsp;Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
 g is an ... object returning values of unsigned integral type ..."
@@ -4842,6 +4094,11 @@ Mont Tremblant:  Both s and g should be unsigned long.
 This should refer to the constructor signatures. Jens  provided wording post Mont Tremblant.
 ]</i></p>
 
+<p><i>[
+Berlin:  N1932 adopts the proposed resolution:  see 26.3.1.3/1e and Table 3 row 2. Moved
+to Ready.
+]</i></p>
+
 <p><b>Rationale:</b></p>
 <p>
 Jens:  Just requiring X(unsigned long) still makes it possible
@@ -4854,254 +4111,7 @@ signature.  u.seed(s) is covered by its reference to X(s), same
 arguments.
 </p>
 <hr>
-<a name="505"><h3>505.&nbsp;Result_type in random distribution requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-Table 17: Random distribution requirements
-</p>
-<p>
-Row 1 requires that each random distribution provide a nested type "input_type";
-this type denotes the type of the values that the distribution consumes.
-</p>
-<p>
-Inspection of all distributions in [tr.rand.dist] reveals that each distribution
-provides a second typedef ("result_type") that denotes the type of the values the
-distribution produces when called.  
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-It seems to me that this is also a requirement
-for all distributions and should therefore be  indicated as such via a new second
-row to this table 17:
-</p>
-<table border="1" cellpadding="5">
-<tbody><tr>
-<td>X::result_type</td>
-<td>T</td>
-<td>---</td>
-<td>compile-time</td>
-</tr>
-</tbody></table>
-<hr>
-<a name="506"><h3>506.&nbsp;Requirements of Distribution parameter for variate_generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-Paragraph 3 requires that template argument U (which corresponds to template
-parameter Engine) satisfy all uniform random number generator requirements.
-However, there is no  analogous requirement regarding the template argument
-that corresponds to template parameter Distribution.  We believe there should
-be, and that it should require that this template argument satisfy all random
-distribution requirements.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
-</p>
-<p>
-Consequence 2: Add max() and min() functions to those distributions that
-do not already have them.
-</p>
-
-<p><i>[
-Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
-Marc supports having min and max to satisfy generic programming interface.
-]</i></p>
-
-<hr>
-<a name="507"><h3>507.&nbsp;Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-Paragraph 11 of [tr.rand.var] equires that the member template
-</p>
-<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
-</pre></blockquote>
-<p>
-return
-</p>
-<blockquote><pre>distribution()(e, value)
-</pre></blockquote>
-<p>
-However, not all distributions have an operator() with a corresponding signature.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-We therefore  recommend that we insert the following precondition before paragraph 11:
-</p>
-<blockquote>
-Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
-</blockquote>
-<hr>
-<a name="508"><h3>508.&nbsp;Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-The fifth of these engines with predefined parameters, ranlux64_base_01,
-appears to have an unintentional error for which there is a simple correction.
-The two pre-defined  subtract_with_carry_01 engines are given as: 
-</p>
-<blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
-typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
-</pre></blockquote>
-<p>
-We demonstrate below that ranlux64_base_01 fails to meet the intent of the
-random number generation proposal, but that the simple correction to
-</p>
-<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
-</pre></blockquote>
-<p>
-does meet the intent of defining well-known good parameterizations.
-</p>
-<p>
-The ranlux64_base_01 engine as presented fails to meet the intent for
-predefined engines, stated in proposal N1398 (section E):
-</p>
-<blockquote><p>
-In order to make good random numbers available to a large number of library
-users, this proposal not only defines generic random-number engines, but also
-provides a number of predefined well-known good parameterizations for those.
-</p></blockquote>
-<p>
-The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
-long period and so meets this criterion.  This property makes it suitable for
-use in the excellent discard_block  engines defined subsequently.  The proof
-of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
-+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
-as defined in [tr.rand.eng.sub1]).
-</p>
-<p>
-The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
-For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
-explicit factorization  would be a challenge).  In consequence, while it is
-certainly possible for some seeding states that this engine would have a very
-long period, it is not at all Òwell-knownÓ that this is the case. The intent
-in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
-use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
-but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
-to deliver 48 random bits at a time rather than 24.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-To achieve this intended behavior, the correct template parameteriztion  would be:
-</p>
-<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
-</pre></blockquote>
-<p>
-The sequence of mantissa bits delivered by this is isomorphic (treating each
-double as having the  bits of two floats) to that delivered by ranlux_base_01.
-</p>
-<p>
-<b>References:</b>
-</p>
-<ol>
-<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
-<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
-<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
-</ol>
-
-<hr>
-<a name="509"><h3>509.&nbsp;Uniform_int template parameters</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.iunif"> [tr.rand.dist.iunif]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
-template parameter, IntType, used as the input_type and as the result_type
-of the distribution.  We believe there is no reason to conflate these types
-in this way.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-We recommend that there be a second template  parameter to
-reflect the distributionÕs input_type, and that the existing first template
-parameter continue to reflect (solely) the result_type:
-</p>
-<blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
-class uniform_int
-{
-public:
-  // types
-  typedef  UIntType  input_type;
-  typedef  IntType   result_type;
-</pre></blockquote>
-<hr>
-<a name="510"><h3>510.&nbsp;Input_type for bernoulli_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bern"> [tr.rand.dist.bern]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-In [tr.rand.dist.bern] the distribution currently requires;
-</p>
-<blockquote><pre>typedef  int  input_type;
-</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-We believe this is an unfortunate choice, and recommend instead:
-</p>
-<blockquote><pre>typedef  unsigned int  input_type;
-</pre></blockquote>
-<hr>
-<a name="511"><h3>511.&nbsp;Input_type for binomial_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-Unlike all other distributions in TR1, this binomial_distribution has an
-implementation-defined  input_type.  We believe this is an unfortunate choice,
-because it hinders users from writing portable code.  It also hinders the
-writing of compliance tests.  We recommend instead:
-</p>
-<blockquote><pre>typedef  RealType  input_type;
-</pre></blockquote>
-<p>
-While this choice is somewhat arbitrary (as it was for some of the other
-distributions), we make  this particular choice because (unlike all other
-distributions) otherwise this template would not publish its RealType
-argument and so users could not write generic code that accessed this
-second template parameter.  In this respect, the choice is consistent with
-the other distributions in  TR1. 
-</p>
-<p>
-We have two reasons for recommending that a real type be specified instead.
-One reason is  based specifically on characteristics of binomial distribution
-implementations, while the other is based on mathematical characteristics of
-probability distribution functions in general.
-</p>
-<p>
-Implementations of binomial distributions commonly use Stirling approximations
-for values in certain ranges.  It is far more natural to use real values to
-represent these approximations than it would be to use integral values to do
-so.  In other ranges, implementations reply on the Bernoulli  distribution to
-obtain values.  While TR1Õs bernoulli_distribution::input_type is specified as
-int, we believe this would be better specified as double.
-</p>
-<p>
-This brings us to our main point:  The notion of a random distribution rests
-on the notion of a cumulative distribution function, which in turn mathematically
-depends on a continuous dependent variable.  Indeed, such a distribution function
-would be meaningless if it depended on  discrete values such as integersÑand this
-remains true even if the distribution function were to take discrete steps.
-</p>
-<p>
-Although this note is specifically about binomial_distribution::input_type,
-we intend to recommend that all of the random distributionsÕ input_types be
-specified as a real type (either a RealType template parameter, or double,
-as appropriate).
-</p>
-<p>
-Of the nine distributions in TR1, four already have this characteristic
-(uniform_real, exponential_distribution, normal_distribution, and
-gamma_distribution).  We have already argued the case for the binomial the
-remaining four distributions.
-</p>
-<p>
-In the case of uniform_int, we believe that the calculations to produce an
-integer result in a  specified range from an integer in a different specified
-range is best done using real arithmetic.  This is because it involves a
-product, one of whose terms is the ratio of the extents of the two ranges.
-Without real arithmetic, the results become less uniform: some numbers become
-more  (or less) probable that they should be.  This is, of course, undesireable
-behavior in a uniform distribution.
-</p>
-<p>
-Finally, we believe that in the case of the bernoulli_distribution (briefly
-mentioned earlier), as well as the cases of the geometric_distribution and the
-poisson_distribution, it would be far more natural to have a real input_type.
-This is because the most natural computation involves the  random number
-delivered and the distributionÕs parameter p (in the case of bernoulli_distribution,
-for example, the computation is a comparison against p), and p is already specified
-in each case as having some real type.
-</p>
-<p><b>Proposed resolution:</b></p>
-<blockquote><pre>typedef  RealType  input_type;
-</pre></blockquote>
-<hr>
-<a name="512"><h3>512.&nbsp;Seeding subtract_with_carry_01 from a single unsigned long</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<a name="512"><h3>512.&nbsp;Seeding subtract_with_carry_01 from a single unsigned long</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01  engine
 is to be seeded given a single unsigned long.  This algorithm is seriously
@@ -5156,6 +4166,12 @@ else sets carry<tt>(-1) = 0</tt>.</del>
 Jens provided revised wording post Mont Tremblant.
 ]</i></p>
 
+<p><i>[
+Berlin: N1932 adopts the originally-proposed resolution of the issue.
+Jens's supplied wording is a clearer description of what is
+intended.  Moved to Ready.
+]</i></p>
+
 <p><b>Rationale:</b></p>
 <p>
 Jens: I'm using an explicit type here, because fixing the
@@ -5163,70 +4179,7 @@ prose would probably not qualify for the (with issue <a href="http://www.open-st
 stricter) requirements we have for seed(Gen&amp;).
 </p>
 <hr>
-<a name="513"><h3>513.&nbsp;Size of state for subtract_with_carry_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-Paragraph 3 begins:
-</p>
-<blockquote>
-The size of the state is r.
-</blockquote>
-<p>
-However, this is not quite consistent with the remainder of the paragraph
-which specifies a total  of nr+1 items in the textual representation of
-the state.  We recommend the sentence be corrected to match:
-</p>
-<blockquote>
-The size of the state is nr+1.
-</blockquote>
-<p>
-To give meaning to the coefficient n, it may be also desirable to move
-nÕs definition from later in the paragraph.  Either of the following
-seem reasonable formulations:
-</p>
-<blockquote>
-With n=..., the size of the state is nr+1.
-</blockquote>
-<blockquote>
-The size of the state is nr+1, where n=... .
-</blockquote>
-<p>
-</p>
-<p><b>Proposed resolution:</b></p>
-<p><i>[
-Jens:  I plead for "NAD" on the grounds that "size of state" is only
-used as an argument for big-O complexity notation, thus
-constant factors and additions don't count.
-]</i></p>
-<hr>
-<a name="514"><h3>514.&nbsp;Size of state for subtract_with_carry</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub"> [tr.rand.eng.sub]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-Paragraph 2 begins:
-</p>
-<blockquote>
-The size of the state is r.
-</blockquote>
-<p>
-However, the next sentence specifies a total of r+1 items in the textual
-representation of the state,  r specific xÕs as well as a specific carry.
-This makes a total of r+1 items that constitute the size of the state,
-rather than r.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-We recommend the sentence be corrected to match:
-</p>
-<blockquote>
- The size of the state is r+1.
-</blockquote>
-
-<p><i>[
-Jens:  I plead for "NAD" on the grounds that "size of state" is only
-used as an argument for big-O complexity notation, thus
-constant factors and additions don't count.
-]</i></p>
-
-<hr>
-<a name="515"><h3>515.&nbsp;Random number engine traits</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<a name="515"><h3>515.&nbsp;Random number engine traits</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 To accompany the concept of a pseudo-random number engine as defined in Table 17,
 we propose and recommend an adjunct template, engine_traits, to be declared in
@@ -5275,8 +4228,14 @@ complete specialization of this new engine_traits template.
 <p>
 
 </p>
+
+<p><i>[
+Berlin:  Walter: While useful for implementation per TR1, N1932 has no need for this
+feature.
+]</i></p>
+
 <hr>
-<a name="516"><h3>516.&nbsp;Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<a name="516"><h3>516.&nbsp;Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 Paragraph 6 says:
 </p>
@@ -5294,27 +4253,7 @@ as the context seems to require only 32-bit quantities be used here.
 </p>
 <p><b>Proposed resolution:</b></p>
 <p>
-
-</p>
-<hr>
-<a name="517"><h3>517.&nbsp;Should include name in external representation</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-The last two rows of Table 16 deal with the i/o requirements of an engine,
-specifying that the textual representation of an engineÕs state,
-appropriately formatted, constitute the engineÕs  external representation.
-</p>
-<p>
-This seems adequate when an engineÕs type is known.  However, it seems
-inadequate in the  context of generic code, where it becomes useful and
-perhaps even necessary to determine an engineÕs type via input.
-</p>
-<p>
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-We therefore recommend that, in each of these two rows of Table 16, the
-text "textual representation" be expanded so as to read "engine name
-followed by the textual representation."
+Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7.  Moved to Ready.
 </p>
 <hr>
 <a name="518"><h3>518.&nbsp;Are insert and erase stable for unordered_multiset and unordered_multimap?</h3></a><p><b>Section:</b>&nbsp;TR1 6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.hash"> [tr.hash]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
@@ -5327,28 +4266,6 @@ The same issue applies to unordered_multiset and unordered_multimap.
 <p>
 </p>
 <hr>
-<a name="519"><h3>519.&nbsp;Data() undocumented</h3></a><p><b>Section:</b>&nbsp;TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
-<p>
-<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a new section, after 6.2.2.3:
-</p>
-<blockquote><pre>T*       data()
-const T* data() const;
-</pre></blockquote>
-<p>
-<b>Returns:</b> <tt>elems</tt>.
-</p>
-<p>
-Change 6.2.2.4/2 to:
-</p>
-<blockquote>
-In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
-of <tt>data()</tt> is unspecified.
-</blockquote>
-<hr>
 <a name="520"><h3>520.&nbsp;Result_of and pointers to data members</h3></a><p><b>Section:</b>&nbsp;TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 In the original proposal for binders, the return type of bind() when
@@ -5365,7 +4282,7 @@ to  member data.
 Pete and Peter will provide wording.
 ]</i></p>
 <hr>
-<a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
 derived from unary_function&lt;T, R&gt; if T is:
@@ -5391,11 +4308,48 @@ a pointer to a member function R T0::f(T2) cv (where cv represents the member
 function's cv-qualifiers); the type T1 is cv T0*
 </blockquote>
 <p><b>Proposed resolution:</b></p>
+
+<p>
+Change bullet item 2 in 2.1.2/3:
+</p>
+
+<blockquote>
+<ul>
+<li>
+a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
+the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return 
+type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
+(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
+the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
+</li>
+</ul>
+</blockquote>
+
+<p>
+Change bullet item 2 in 2.1.2/4:
+</p>
+
+<blockquote>
+<ul>
+<li>
+a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
+of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and 
+<tt>R</tt> is the return type of the pointer to member function</del>
+<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
+function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
+</li>
+</ul>
+</blockquote>
+
 <hr>
-<a name="522"><h3>522.&nbsp;Tuple doesn't define swap</h3></a><p><b>Section:</b>&nbsp;TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Koenig&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<a name="522"><h3>522.&nbsp;Tuple doesn't define swap</h3></a><p><b>Section:</b>&nbsp;TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Koenig&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
 <p>
 Tuple doesn't define swap().  It should.
 </p>
+<p><i>[
+Berlin: Doug to provide wording.
+]</i></p>
+
 <p><b>Proposed resolution:</b></p>
 <hr>
 <a name="523"><h3>523.&nbsp;regex case-insensitive character ranges are unimplementable as specified</h3></a><p><b>Section:</b>&nbsp;TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Eric Niebler&nbsp; <b>Date:</b>&nbsp;1 Jul 2005</p>
@@ -5568,15 +4522,19 @@ For what it's worth, John has also expressed his preference for option
 </p>
 <p><b>Proposed resolution:</b></p>
 <hr>
-<a name="525"><h3>525.&nbsp;type traits definitions not clear</h3></a><p><b>Section:</b>&nbsp;TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;11 Jul 2005</p>
+<a name="525"><h3>525.&nbsp;type traits definitions not clear</h3></a><p><b>Section:</b>&nbsp;TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;11 Jul 2005</p>
 <p>
 It is not completely clear how the primary type traits deal with
 cv-qualified types.  And several of the secondary type traits
 seem to be lacking a definition.
 </p>
+
+<p><i>[
+Berlin:  Howard to provide wording.
+]</i></p>
 <p><b>Proposed resolution:</b></p>
 <hr>
-<a name="526"><h3>526.&nbsp;Is it undefined if a function in the standard changes in parameters?</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Jefferson&nbsp; <b>Date:</b>&nbsp;14 Sep 2005</p>
+<a name="526"><h3>526.&nbsp;Is it undefined if a function in the standard changes in parameters?</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Jefferson&nbsp; <b>Date:</b>&nbsp;14 Sep 2005</p>
 <p>
 Problem: There are a number of places in the C++ standard library where
 it is possible to write what appear to be sensible ways of calling
@@ -5684,11 +4642,18 @@ Matt Austern adds that this issue also exists for the <tt>insert</tt> and
 <tt>erase</tt> members of the ordered and unordered associative containers.
 </p>
 
+<p><i>[
+Berlin: Lots of controversey over how this should be solved. Lots of confusion
+as to whether we're talking about self referencing iterators or references.
+Needs a good survey as to the cases where this matters, for which
+implementations, and how expensive it is to fix each case.
+]</i></p>
+
 <p><b>Proposed resolution:</b></p>
 <p>
 </p>
 <hr>
-<a name="527"><h3>527.&nbsp;tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b>&nbsp;TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;01 Oct 2005</p>
+<a name="527"><h3>527.&nbsp;tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b>&nbsp;TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;01 Oct 2005</p>
 <p>
 The original bind proposal gives the guarantee that tr1::bind(f, t1,
 ..., tN) does not throw when the copy constructors of f, t1, ..., tN
@@ -5702,11 +4667,16 @@ This guarantee is not present in the final version of TR1.
 <p>
 I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
 </p>
+
+<p><i>[
+Berlin: not quite editorial, needs proposed wording.
+]</i></p>
+
 <p><b>Proposed resolution:</b></p>
 <p>
 </p>
 <hr>
-<a name="528"><h3>528.&nbsp;TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b>&nbsp;TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Oct 2005</p>
+<a name="528"><h3>528.&nbsp;TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b>&nbsp;TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Oct 2005</p>
 <p>
 while implementing the resolution of issue 6.19 I'm noticing the
 following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
@@ -5738,13 +4708,32 @@ Add to 6.3.4.3p2 (and 6.3.4.5p2):
 <p>
 2  ... The iterator and const_iterator types are both <del>const</del>
 <ins>constant</ins> iterator types.
-It is unspecified whether they are the same type. <ins>If they are the
-same type, those signatures that become otherwise indistinguishable
-collapse into a single signature.</ins>
+It is unspecified whether they are the same type. 
 </p>
 
+<p>
+Add a new subsection to 17.4.4 [lib.conforming]:
+</p>
+
+<blockquote>
+<p>
+An implementation shall not supply an overloaded function
+       signature specified in any library clause if such a signature
+       would be inherently ambiguous during overload resolution
+       due to two library types referring to the same type.
+</p>
+<p>
+       [Note: For example, this occurs when a container's iterator
+       and const_iterator types are the same. -- end note]
+</p>
+</blockquote>
+
+<p><i>[
+Post-Berlin: Beman supplied wording.
+]</i></p>
+
 <hr>
-<a name="529"><h3>529.&nbsp;The standard encourages redundant and confusing preconditions</h3></a><p><b>Section:</b>&nbsp;17.4.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.required"> [lib.res.on.required]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;David Abrahams&nbsp; <b>Date:</b>&nbsp;25 Oct 2005</p>
+<a name="529"><h3>529.&nbsp;The standard encourages redundant and confusing preconditions</h3></a><p><b>Section:</b>&nbsp;17.4.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.required"> [lib.res.on.required]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;David Abrahams&nbsp; <b>Date:</b>&nbsp;25 Oct 2005</p>
 <p>
 17.4.3.8/1 says:
 </p>
@@ -5802,8 +4791,13 @@ an exception when the precondition is violated</del>.
 2. Go through and remove redundant Requires: clauses.  Specifics to be
    provided by Dave A.
 </p>
+
+<p><i>[
+Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
+]</i></p>
+
 <hr>
-<a name="530"><h3>530.&nbsp;Must elements of a string be contiguous?</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Nov 2005</p>
+<a name="530"><h3>530.&nbsp;Must elements of a string be contiguous?</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Nov 2005</p>
 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
 &nbsp;&nbsp; that the elements of a vector must be stored in contiguous memory.
 &nbsp;&nbsp; Should the same also apply to <tt>basic_string</tt>?</p>
@@ -5821,7 +4815,7 @@ an exception when the precondition is violated</del>.
 &nbsp; it.
 </p>
 <p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 23.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative"> [lib.associative]</a>,
+<p>Add the following text to the end of 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>,
 paragraph 2. </p>
 
 <blockquote>
@@ -5833,7 +4827,7 @@ paragraph 2. </p>
   </p>
 </blockquote>
 <hr>
-<a name="531"><h3>531.&nbsp;array forms of unformatted input functions</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;23 Nov 2005</p>
+<a name="531"><h3>531.&nbsp;array forms of unformatted input functions</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;23 Nov 2005</p>
 <p>
 The array forms of unformatted input functions don't seem to have well-defined
 semantics for zero-element arrays in a couple of cases. The affected ones
@@ -5885,7 +4879,7 @@ In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null charact
             </blockquote>
         <p></p>
 <hr>
-<a name="532"><h3>532.&nbsp;Tuple comparison</h3></a><p><b>Section:</b>&nbsp;TR1 6.1.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple.rel"> [tr.tuple.rel]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;David Abrahams&nbsp; <b>Date:</b>&nbsp;29 Nov 2005</p>
+<a name="532"><h3>532.&nbsp;Tuple comparison</h3></a><p><b>Section:</b>&nbsp;TR1 6.1.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple.rel"> [tr.tuple.rel]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;David Abrahams&nbsp; <b>Date:</b>&nbsp;29 Nov 2005</p>
 <p>
 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
 defined in terms of std::less rather than operator&lt;, in order to
@@ -5934,8 +4928,14 @@ to:
      otherwise, returns (bool)(x &lt; y)
 </p>
 </blockquote>
+
+<p><i>[
+Berlin: This issue is much bigger than just tuple (pair, containers,
+algorithms). Dietmar will survey and work up proposed wording.
+]</i></p>
+
 <hr>
-<a name="534"><h3>534.&nbsp;Missing basic_string members</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Alisdair Meredith&nbsp; <b>Date:</b>&nbsp;16 Nov 2005</p>
+<a name="534"><h3>534.&nbsp;Missing basic_string members</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Alisdair Meredith&nbsp; <b>Date:</b>&nbsp;16 Nov 2005</p>
 <p>
 OK, we all know std::basic_string is bloated and already has way too
 many members.  However, I propose it is missing 3 useful members that
@@ -5983,9 +4983,80 @@ added to vector, or at() member added to the maps.
 </p>
 <p><b>Proposed resolution:</b></p>
 <p>
+Add the following members to definition of class template basic_string, 21.3p7
 </p>
+<blockquote><pre>void pop_back ()
+
+const charT &amp; front() const
+charT &amp; front()
+
+const charT &amp; back() const
+charT &amp; back()
+</pre></blockquote>
+<p>
+Add the following paragraphs to basic_string description
+</p>
+
+<p>
+21.3.4p5
+</p>
+<blockquote>
+<pre>const charT &amp; front() const
+charT &amp; front()
+</pre>
+<p>
+<i>Precondition:</i> <tt>!empty()</tt>
+</p>
+<p>
+<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
+</p>
+</blockquote>
+
+<p>
+21.3.4p6
+</p>
+<blockquote>
+<pre>const charT &amp; back() const
+charT &amp; back()
+</pre>
+<p>
+<i>Precondition:</i> <tt>!empty()</tt>
+</p>
+<p>
+<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
+</p>
+</blockquote>
+
+<p>
+21.3.5.5p10
+</p>
+<blockquote>
+<pre>void pop_back ()
+</pre>
+<p>
+<i>Precondition:</i> <tt>!empty()</tt>
+</p>
+<p>
+<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
+</p>
+</blockquote>
+
+<p>
+Update Table 71: (optional sequence operations)
+Add basic_string to the list of containers for the following operations.
+</p>
+<blockquote><pre>a.front()
+a.back()
+a.push_back()
+a.pop_back()
+a[n]
+</pre></blockquote>
+
+<p><i>[
+Berlin: Has support.  Alisdair provided wording.
+]</i></p>
 <hr>
-<a name="535"><h3>535.&nbsp;std::string::swap specification poorly worded</h3></a><p><b>Section:</b>&nbsp;21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;14 Dec 2005</p>
+<a name="535"><h3>535.&nbsp;std::string::swap specification poorly worded</h3></a><p><b>Section:</b>&nbsp;21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;14 Dec 2005</p>
 <p>
 std::string::swap currently says for effects and postcondition:
 </p>
@@ -6020,7 +5091,7 @@ characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
 </p>
 </blockquote>
 <hr>
-<a name="536"><h3>536.&nbsp;Container iterator constructor and explicit convertibility</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Joaquín M López Muñoz&nbsp; <b>Date:</b>&nbsp;17 Dec 2005</p>
+<a name="536"><h3>536.&nbsp;Container iterator constructor and explicit convertibility</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Joaquín M López Muñoz&nbsp; <b>Date:</b>&nbsp;17 Dec 2005</p>
 <p>
 The iterator constructor X(i,j) for containers as defined in 23.1.1 and
 23.2.2 does only require that i and j be input iterators but
@@ -6073,8 +5144,11 @@ int main()
 <p><b>Proposed resolution:</b></p>
 <p>
 </p>
+<p><i>[
+Berlin: Some support, not universal, for respecting the explicit qualifier.
+]</i></p>
 <hr>
-<a name="537"><h3>537.&nbsp;Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Feb 2006</p>
+<a name="537"><h3>537.&nbsp;Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Feb 2006</p>
 <p>
 In the most recent working draft, I'm still seeing:
 </p>
@@ -6116,7 +5190,7 @@ After 27.6.2.4p3 change:
 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
 </pre></blockquote>
 <hr>
-<a name="538"><h3>538.&nbsp;241 again: Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;9 Feb 2006</p>
+<a name="538"><h3>538.&nbsp;241 again: Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;9 Feb 2006</p>
 <p>
 I believe I botched the resolution of
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
@@ -6154,15 +5228,15 @@ This latter requirement does not necessarily imply that you can:
 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
-<del>shall</del> <ins>must</ins>
+shall
 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
 requirements of forward iterator then the <del>value type</del> 
 <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
-must be CopyConstructible (20.1.3) <ins>and CopyAssignable</ins>.
+must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
 Otherwise CopyConstructible is not required.
 </blockquote>
 <hr>
-<a name="539"><h3>539.&nbsp;partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b>&nbsp;26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Marc Schoolderman&nbsp; <b>Date:</b>&nbsp;6 Feb 2006</p>
+<a name="539"><h3>539.&nbsp;partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b>&nbsp;26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Marc Schoolderman&nbsp; <b>Date:</b>&nbsp;6 Feb 2006</p>
 <p>
 There are some problems in the definition of partial_sum and
 adjacent_difference in 26.4 [lib.numeric.ops]
@@ -6304,8 +5378,12 @@ The type of <tt>*first</tt> shall meet the requirements of
 <p><b>Proposed resolution:</b></p>
 <p>
 </p>
+<p><i>[
+Berlin: Giving output iterator's value_types very controversial. Suggestion of
+adding signatures to allow user to specify "accumulator".
+]</i></p>
 <hr>
-<a name="540"><h3>540.&nbsp;shared_ptr&lt;void&gt;::operator*()</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2005</p>
+<a name="540"><h3>540.&nbsp;shared_ptr&lt;void&gt;::operator*()</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2005</p>
 <p>
 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
 that talks about the operator*() member function of shared_ptr:
@@ -6552,7 +5630,7 @@ want. Shouldn't we be performing a conversion to a floating-point type first?
 <p>
 </p>
 <hr>
-<a name="548"><h3>548.&nbsp;May random_device block?</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.device"> [tr.rand.device]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;10 Jan 2006</p>
+<a name="548"><h3>548.&nbsp;May random_device block?</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.device"> [tr.rand.device]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;10 Jan 2006</p>
 <p>
 Class random_device "produces non-deterministic random numbers", using some
 external source of entropy. In most real-world systems, the amount of available
@@ -6565,11 +5643,17 @@ the entropy pool is empty, reads to /dev/random will block until additional
 environmental noise is gathered." Programmers need to know whether random_device
 is permitted to (or possibly even required to?) behave the same way.
 </p>
+
+<p><i>[
+Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
+may block?
+]</i></p>
+
 <p><b>Proposed resolution:</b></p>
 <p>
 </p>
 <hr>
-<a name="549"><h3>549.&nbsp;Undefined variable in binomial_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;10 Jan 2006</p>
+<a name="549"><h3>549.&nbsp;Undefined variable in binomial_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;10 Jan 2006</p>
 <p>
 Paragraph 1 says that "A binomial distributon random distribution produces
 integer values i&gt;0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
@@ -6578,6 +5662,7 @@ are. What's n?
 </p>
 <p><b>Proposed resolution:</b></p>
 <p>
+Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
 </p>
 <hr>
 <a name="550"><h3>550.&nbsp;What should the return type of pow(float,int) be?</h3></a><p><b>Section:</b>&nbsp;26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;12 Jan 2006</p>
@@ -7449,5 +6534,194 @@ location of the array.
 
             </p>
         </blockquote>
+<hr>
+<a name="567"><h3>567.&nbsp;streambuf inserter and extractor should be unformatted</h3></a><p><b>Section:</b>&nbsp;27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;25 Feb 2006</p>
+        <p>
+
+Issue  60 explicitly made  the extractor  and inserter  operators that
+take a  <tt>basic_streambuf*</tt> argument formatted  input and output
+functions,  respectively.  I  believe that's  wrong, certainly  in the
+case of  the extractor, since formatted functions  begin by extracting
+and  discarding  whitespace.  The  extractor  should  not discard  any
+characters.
+
+        </p>
+<p><b>Proposed resolution:</b></p>
+        <p>
+
+I propose to  change each operator to behave  as unformatted input and
+output function,  respectively. The changes below are  relative to the
+working draft document number N1804.
+
+        </p>
+        <p>
+
+Specifically, change 27.6.1.2.3, p14 as follows:
+
+        </p>
+
+        <p>
+            </p><blockquote>
+
+<i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
+(as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
+1</ins>).
+
+            </blockquote>
+        <p></p>
+        <p>
+
+And change 27.6.2.5.3, p7 as follows:
+
+        </p>
+
+        <p>
+            </p><blockquote>
+
+<i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
+(as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
+1</ins>).
+
+            </blockquote>
+        <p></p>
+<hr>
+<a name="568"><h3>568.&nbsp;log2 overloads missing</h3></a><p><b>Section:</b>&nbsp;TR1 8.16.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cmath.over"> [tr.c99.cmath.over]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;7 Mar 2006</p>
+<p>
+<tt>log2</tt> is missing from the list of "additional overloads" in 8.16.4p1.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add <tt>log2</tt> to the list of functions in 8.16.4p1.
+</p>
+<hr>
+<a name="569"><h3>569.&nbsp;Postcondition for basic_ios::clear(iostate) incorrectly stated</h3></a><p><b>Section:</b>&nbsp;27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Seungbeom Kim&nbsp; <b>Date:</b>&nbsp;10 Mar 2006</p>
+<p>
+Section: 27.4.4.3 [lib.iostate.flags]
+</p>
+<p>
+Paragraph 4 says:
+</p>
+<blockquote>
+<blockquote><pre>void clear(iostate <i>state</i> = goodbit);
+</pre></blockquote>
+<p>
+<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
+otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
+</p>
+</blockquote>
+
+<p>
+The postcondition "rdstate()==state|ios_base::badbit" is parsed as
+"(rdstate()==state)|ios_base::badbit", which is probably what the
+committee meant.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 27.4.4.3p4:
+</p>
+<blockquote>
+<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
+otherwise <tt>rdstate()==<ins>(</ins><i>state</i>|ios_base::badbit</tt><ins>)</ins>.
+</blockquote>
+<hr>
+<a name="570"><h3>570.&nbsp;Request adding additional explicit specializations of char_traits</h3></a><p><b>Section:</b>&nbsp;21.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits"> [lib.char.traits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;6 Apr 2006</p>
+<p>
+Currently, the Standard Library specifies only a declaration for template class
+char_traits&lt;&gt; and requires the implementation provide two explicit
+specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
+should require explicit specializations for all built-in character types, i.e.
+char, wchar_t, unsigned char, and signed char.
+</p>
+<p>
+I have put together a paper (N1985) that describes this in more detail and
+includes all the necessary wording.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+<hr>
+<a name="571"><h3>571.&nbsp;Update C90 references to C99?</h3></a><p><b>Section:</b>&nbsp;1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.refs"> [intro.refs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;8 Apr 2006</p>
+<p>
+1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
+9899:1990, Programming languages - C. Should that be changed to ISO/IEC
+9899:1999?
+</p>
+<p>
+What impact does this have on the library?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 1.2/1 [intro.refs] of the WP, change:
+</p>
+<blockquote>
+<ul>
+<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i>
+</li>
+</ul>
+</blockquote>
+
+<hr>
+<a name="572"><h3>572.&nbsp;Oops, we gave 507 WP status</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;11 Apr 2006</p>
+<p>
+In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
+variate_generator has been eliminated.  Then in full committee we voted to give
+this issue WP status (mistakenly).
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike the proposed resolution of issue 507.
+</p>
+<hr>
+<a name="573"><h3>573.&nbsp;C++0x file positioning should handle modern file sizes</h3></a><p><b>Section:</b>&nbsp;27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Your name&nbsp; <b>Date:</b>&nbsp;29 Feb 1900</p>
+<p>
+There are two deficiencies related to file sizes:
+</p>
+<ol>
+<li>It doesn't appear that the Standard Library is specified in
+      a way that handles modern file sizes, which are often too
+      large to be represented by an unsigned long.</li>
+
+<li>The std::fpos class does not currently have the ability to
+      set/get file positions.</li>
+</ol>
+<p>
+The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
+</p>
+<ol type="A">
+<li>Defining fpos_t be long long, which is large enough to
+      represent any file position likely in the foreseeable future.</li>
+
+<li>Adding member functions to class fpos. For example,
+<blockquote><pre>fpos_t seekpos() const;
+</pre></blockquote>
+</li>
+</ol>
+<p>
+Because there are so many types relating to file positions and offsets (fpos_t,
+fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
+perhaps more), it is difficult to know if the Dinkumware extensions are
+sufficient. But they seem a useful starting place for discussions, and they do
+represent existing practice.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+<hr>
+<a name="574"><h3>574.&nbsp;DR 369 Contradicts Text</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;18 Apr 2006</p>
+<p>
+lib.iostream.objects requires that the standard stream objects are never
+destroyed, and it requires that they be destroyed.
+</p>
+<p>
+DR 369 adds words to say that we really mean for ios_base::Init objects to force
+construction of standard stream objects. It ends, though, with the phrase "these
+stream objects shall be destroyed after the destruction of dynamically ...".
+However, the rule for destruction is stated in the standard: "The objects are
+not destroyed during program execution."
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
 <p>----- End of document -----</p>
 </body></html>
\ No newline at end of file
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html
index 8d9138589c1..1907a4a8502 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head>
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N1950=06-0020</td>
+<td align="left">N2001=06-0071</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2006-02-24</td>
+<td align="left">2006-04-21</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head>
 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Defect Report List (Revision R41)</h1>
+<h1>C++ Standard Library Defect Report List (Revision R42)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
     <ul>
@@ -45,6 +45,15 @@ del {background-color:#FFFFA0}</style></head>
   document.</p>
 <h2>Revision History</h2>
 <ul>
+<li>R42: 
+2006-04-21 post-Berlin mailing.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#549">549</a> to Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review.
+</li>
 <li>R41: 
 2006-02-24 pre-Berlin mailing.
 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>.
@@ -59,9 +68,9 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active
 2005-10-14 post-Mont Tremblant mailing.
 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 </li>
@@ -96,7 +105,7 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#
 <li>R31: 
 2004-07 mid-term mailing: reflects new proposed resolutions and
 new issues received after the post-Sydney mailing.  Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>.
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 </li>
 <li>R30: 
 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
@@ -133,7 +142,7 @@ Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/
 Moved issues in the TC to TC status.
 </li>
 <li>R22: 
-Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
+Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
 </li>
 <li>R21: 
 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
@@ -5367,7 +5376,7 @@ not required elsewhere.</p>
 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
 <hr>
-<a name="186"><h3>186.&nbsp;bitset::set() second parameter should be bool</h3></a><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Darin Adler&nbsp; <b>Date:</b>&nbsp;13 Aug 1999</p>
+<a name="186"></a><h3><a name="186">186.&nbsp;bitset::set() second parameter should be bool</a></h3><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Darin Adler&nbsp; <b>Date:</b>&nbsp;13 Aug 1999</p>
 <p>In section 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
 bitset::set operation to take a second parameter of type int. The
 function tests whether this value is non-zero to determine whether to
@@ -7267,6 +7276,69 @@ had language that made this an unambiguous requirement; those words
 were moved to a place where their context made them less clear.  See
 Jerry Schwarz's message c++std-lib-7618.</p>
 <hr>
+<a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
+<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
+of <tt>vector::insert</tt>:</p>
+
+   <blockquote>
+   Complexity: If first and last are forward iterators, bidirectional
+   iterators, or random access iterators, the complexity is linear in
+   the number of elements in the range [first, last) plus the distance
+   to the end of the vector. If they are input iterators, the complexity
+   is proportional to the number of elements in the range [first, last)
+   times the distance to the end of the vector.
+   </blockquote>
+
+<p>First, this fails to address the non-iterator forms of
+<tt>insert</tt>.</p>
+
+<p>Second, the complexity for input iterators misses an edge case --
+it requires that an arbitrary number of elements can be added at
+the end of a <tt>vector</tt> in constant time.</p>
+
+<p>I looked to see if <tt>deque</tt> had a similar problem, and was
+surprised to find that <tt>deque</tt> places no requirement on the
+complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
+paragraph 3):</p>
+
+   <blockquote>
+   Complexity: In the worst case, inserting a single element into a
+   deque takes time linear in the minimum of the distance from the
+   insertion point to the beginning of the deque and the distance
+   from the insertion point to the end of the deque. Inserting a
+   single element either at the beginning or end of a deque always
+   takes constant time and causes a single call to the copy constructor
+   of T.
+   </blockquote>
+<p><b>Proposed resolution:</b></p>
+
+<p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p>
+   <blockquote>
+   Complexity: The complexity is linear in the number of elements 
+   inserted plus the distance to the end of the vector.
+   </blockquote>
+
+   <p><i>[For input iterators, one may achieve this complexity by first
+   inserting at the end of the <tt>vector</tt>, and then using
+   <tt>rotate</tt>.]</i></p>
+
+<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p>
+
+   <blockquote>
+   Complexity: The complexity is linear in the number of elements 
+   inserted plus the shorter of the distances to the beginning and
+   end of the deque.  Inserting a single element at either the
+   beginning or the end of a deque causes a single call to the copy
+   constructor of T.
+   </blockquote>
+
+<p><b>Rationale:</b></p>
+<p>This is a real defect, and proposed resolution fixes it: some
+  complexities aren't specified that should be.  This proposed
+  resolution does constrain deque implementations (it rules out the
+  most naive possible implementations), but the LWG doesn't see a
+  reason to permit that implementation.</p>
+<hr>
 <a name="248"><h3>248.&nbsp;time_get fails to set eofbit</h3></a><p><b>Section:</b>&nbsp;22.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.time"> [lib.category.time]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;22 June 2000</p>
 <p>There is no requirement that any of time_get member functions set
 ios::eofbit when they reach the end iterator while parsing their input.
@@ -8936,6 +9008,54 @@ the corresponding member objects of <tt>rhs</tt>, except that...
 assigns to the member objects of <tt>*this</tt> the corresponding member
 objects of <tt>rhs</tt>, except that...
 </blockquote>
+<hr>
+<a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
+<p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
+translation unit that includes a header shall not contain any macros
+that define names declared in that header." As I read this, it
+would mean that the following program is legal:</p>
+
+<pre>  #define npos 3.14
+  #include &lt;sstream&gt;
+</pre>
+
+<p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
+in &lt;string&gt;, and it is hard to imagine an implementation in
+which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
+
+<p>I think that this phrase was probably formulated before it was
+decided that a standard header may freely include other standard
+headers.  The phrase would be perfectly appropriate for C, for
+example.  In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
+it isn't stringent enough.</p>
+<p><b>Proposed resolution:</b></p>
+<p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p>
+<blockquote>
+     <p>Each name defined as a macro in a header is reserved to the
+     implementation for any use if the translation unit includes
+     the header.168)</p>
+
+     <p>A translation unit that includes a header shall not contain any
+     macros that define names declared or defined in that header. Nor shall
+     such a translation unit define macros for names lexically
+     identical to keywords.</p>
+
+     <p>168) It is not permissible to remove a library macro definition by
+     using the #undef directive.</p>
+</blockquote>
+
+<p>with the wording:</p>
+
+<blockquote>
+     <p>A translation unit that includes a standard library header shall not
+     #define or #undef names declared in any standard library header.</p>
+
+     <p>A translation unit shall not #define or #undef names lexically
+     identical to keywords.</p>
+</blockquote>
+
+<p><i>[Lillehammer: Beman provided new wording]</i></p>
+
 <hr>
 <a name="295"><h3>295.&nbsp;Is abs defined in &lt;cmath&gt;?</h3></a><p><b>Section:</b>&nbsp;26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jens Maurer&nbsp; <b>Date:</b>&nbsp;12 Jan 2001</p>
 <p>
@@ -11330,6 +11450,54 @@ prevents locale from being implemented efficiently.
 <p>This change is reasonable becuase it clarifies the intent of this
   part of the standard.</p>
 <hr>
+<a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
+<p>
+The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
+the construction of an unsafe binding between incompatible pointer
+types. For example, given a function whose first parameter type is
+'pointer to T', it's possible without error to bind an argument of
+type 'pointer to U' when U does not derive from T:
+</p>
+<pre>   foo(T*, int);
+
+   struct T {};
+   struct U {};
+
+   U u;
+
+   int* p;
+   int* q;
+
+   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
+</pre>
+
+<p>
+The definition of bind1st() includes a functional-style conversion to
+map its argument to the expected argument type of the bound function
+(see below):
+</p>
+<pre>  typename Operation::first_argument_type(x)
+</pre>
+
+<p>
+A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
+semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
+as a reinterpret_cast, thus masking the error.
+</p>
+
+<p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1:
+  "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
+  favor of <tt>std::tr1::bind</tt>."</p>
+
+<p>(Notes to editor: (1) when and if tr1::bind is incorporated into
+  the standard, "std::tr1::bind" should be changed to "std::bind". (2)
+  20.3.6 should probably be moved to Annex D.</p>
+<p><b>Rationale:</b></p>
+<p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
+  superior solution.  It solves this problem and others.</p>
+<hr>
 <a name="363"><h3>363.&nbsp;Missing exception specification in 27.4.2.1.1</h3></a><p><b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown and Marc Paterno&nbsp; <b>Date:</b>&nbsp;20 May 2002</p>
 <p>
 The destructor of ios_base::failure should have an empty throw
@@ -11413,6 +11581,102 @@ state exposed by the public interface is unchanged.</p>
 <p>Note that implementers can make this change in a binary compatible
 way by providing both overloads; this would be a conforming extension.</p>
 
+<hr>
+<a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
+<p>
+Is it safe to use standard iostream objects from constructors of
+static objects?  Are standard iostream objects constructed and are
+their associations established at that time?
+</p>
+
+<p>Surpisingly enough, Standard does NOT require that.</p>
+
+<p>
+27.3/2 [lib.iostream.objects] guarantees that standard iostream
+objects are constructed and their associations are established before
+the body of main() begins execution.  It also refers to ios_base::Init
+class as the panacea for constructors of static objects.
+</p>
+
+<p>
+However, there's nothing in 27.3 [lib.iostream.objects],
+in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
+that would require implementations to allow access to standard
+iostream objects from constructors of static objects.
+</p>
+
+<p>Details:</p>
+
+<p>Core text refers to some magic object ios_base::Init, which will
+be discussed below:</p>
+
+<blockquote>
+    "The [standard iostream] objects are constructed, and their
+    associations are established at some time prior to or during
+    first time an object of class basic_ios&lt;charT,traits&gt;::Init
+    is constructed, and in any case before the body of main
+    begins execution." (27.3/2 [lib.iostream.objects])
+</blockquote>
+
+<p>
+The first <i>non-normative</i> footnote encourages implementations
+to initialize standard iostream objects earlier than required.
+</p>
+
+<p>However, the second <i>non-normative</i> footnote makes an explicit
+and unsupported claim:</p>
+
+<blockquote>
+  "Constructors and destructors for static objects can access these
+  [standard iostream] objects to read input from stdin or write output
+  to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
+</blockquote>
+
+<p>
+The only bit of magic is related to that ios_base::Init class.  AFAIK,
+the rationale behind ios_base::Init was to bring an instance of this
+class to each translation unit which #included &lt;iostream&gt; or
+related header.  Such an inclusion would support the claim of footnote
+quoted above, because in order to use some standard iostream object it
+is necessary to #include &lt;iostream&gt;.
+</p>
+
+<p>
+However, while Standard explicitly describes ios_base::Init as
+an appropriate class for doing the trick, I failed to found a
+mention of an _instance_ of ios_base::Init in Standard.
+</p>
+<p><b>Proposed resolution:</b></p>
+
+<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
+of the paragraph, the following two sentences:</p>
+
+<blockquote>
+If a translation unit includes &lt;iostream&gt;, or explicitly
+constructs an ios_base::Init object, these stream objects shall
+be constructed before dynamic initialization of non-local
+objects defined later in that translation unit, and these stream
+objects shall be destroyed after the destruction of dynamically
+initialized non-local objects defined later in that translation unit.
+</blockquote>
+
+<p><i>[Lillehammer: Matt provided wording.]</i></p>
+<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
+<p><b>Rationale:</b></p>
+<p>
+The original proposed resolution unconditionally required
+implementations to define an ios_base::Init object of some
+implementation-defined name in the header &lt;iostream&gt;. That's an
+overspecification. First, defining the object may be unnecessary
+and even detrimental to performance if an implementation can
+guarantee that the 8 standard iostream objects will be initialized
+before any other user-defined object in a program. Second, there
+is no need to require implementations to document the name of the
+object.</p>
+
+<p>
+The new proposed resolution gives users guidance on what they need to
+do to ensure that stream objects are constructed during startup.</p>
 <hr>
 <a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
 <p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
@@ -11444,6 +11708,82 @@ with the following signature:</p>
 
 <p><b>Rationale:</b></p>
 <p>Fixes an obvious typo.</p>
+<hr>
+<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
+<p>
+The requirements for multiset and multimap containers (23.1
+[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
+23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
+the stability of the required (mutating) member functions. It appears
+the standard allows these functions to reorder equivalent elements of
+the container at will, yet the pervasive red-black tree implementation
+appears to provide stable behaviour.
+</p>
+
+<p>This is of most concern when considering the behaviour of erase().
+A stability requirement would guarantee the correct working of the
+following 'idiom' that removes elements based on a certain predicate
+function.
+</p>
+
+<pre>  multimap&lt;int, int&gt; m;
+  multimap&lt;int, int&gt;::iterator i = m.begin();
+  while (i != m.end()) {
+      if (pred(i))
+          m.erase (i++);
+      else
+          ++i;
+  }
+</pre>
+
+<p>
+Although clause 23.1.2/8 guarantees that i remains a valid iterator
+througout this loop, absence of the stability requirement could
+potentially result in elements being skipped. This would make
+this code incorrect, and, furthermore, means that there is no way
+of erasing these elements without iterating first over the entire
+container, and second over the elements to be erased. This would
+be unfortunate, and have a negative impact on both performance and
+code simplicity.
+</p>
+
+<p>
+If the stability requirement is intended, it should be made explicit
+(probably through an extra paragraph in clause 23.1.2).
+</p>
+<p>
+If it turns out stability cannot be guaranteed, i'd argue that a
+remark or footnote is called for (also somewhere in clause 23.1.2) to
+warn against relying on stable behaviour (as demonstrated by the code
+above).  If most implementations will display stable behaviour, any
+problems emerging on an implementation without stable behaviour will
+be hard to track down by users. This would also make the need for an
+erase_if() member function that much greater.
+</p>
+
+<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
+
+<p><b>Proposed resolution:</b></p>
+
+<p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4: 
+"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
+  are <i>stable</i>: they preserve the relative ordering of equivalent
+  elements.</p> 
+
+<p><i>[Lillehammer: Matt provided wording]</i></p>
+<p><i>[Joe Gottman points out that the provided wording does not address
+multimap and multiset.  N1780 also addresses this issue and suggests
+wording.]</i></p>
+
+<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>The LWG agrees that this guarantee is necessary for common user
+  idioms to work, and that all existing implementations provide this
+  property.  Note that this resolution guarantees stability for
+  multimap and multiset, not for all associative containers in
+  general.</p>
+
 <hr>
 <a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p><b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
 
@@ -11476,6 +11816,42 @@ paragraph 14 to "ios_base".
 <p><b>Rationale:</b></p>
 <p>Fixes an obvious typo.</p>
 <hr>
+<a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
+<p>
+In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
+the four conditions should be mutually exclusive, but they are not.
+The first two cases, as written, are subcases of the third.</p>
+
+<p>
+As written, it is unclear what should be the result if cases 1 and 2
+are both true, but case 3 is false.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+
+<p>Rewrite these conditions as:</p>
+<blockquote>
+<p>
+  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
+</p>
+
+<p>
+  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
+</p>
+
+<p>
+  (which &amp; (ios_base::in|ios_base::out)) == 
+(ios_base::in|ios_base::out)
+   and way == either ios_base::beg or ios_base::end
+</p>
+
+<p>Otherwise</p>
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>It's clear what we wanted to say, we just failed to say it.  This
+  fixes it.</p>
+<hr>
 <a name="379"><h3>379.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p><b>Section:</b>&nbsp;22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
 <p>
 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
@@ -11651,6 +12027,64 @@ Change the guarantee to "postcondition: r is dereferenceable."
 <p><b>Rationale:</b></p>
 <p>Fixes an obvious typo</p>
 <hr>
+<a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
+<p>
+Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
+states that at most 2 * log(last - first) + 1
+comparisons are allowed for equal_range.
+</p>
+
+<p>It is not possible to implement equal_range with these constraints.</p>
+
+<p>In a range of one element as in:</p>
+<pre>    int x = 1;
+    equal_range(&amp;x, &amp;x + 1, 1)
+</pre>
+
+<p>it is easy to see that at least 2 comparison operations are needed.</p>
+
+<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
+
+<p>I have checked a few libraries and they all use the same (nonconforming)
+algorithm for equal_range that has a complexity of</p>
+<pre>     2* log(distance(first, last)) + 2.
+</pre>
+<p>I guess this is the algorithm that the standard assumes for equal_range.</p>
+
+<p>
+It is easy to see that 2 * log(distance) + 2 comparisons are enough
+since equal range can be implemented with lower_bound and upper_bound
+(both log(distance) + 1).
+</p>
+
+<p>
+I think it is better to require something like 2log(distance) + O(1)  (or
+even logarithmic as multiset::equal_range).
+Then an implementation has more room to optimize for certain cases (e.g.
+have log(distance) characteristics when at most match is found in the range
+but 2log(distance) + 4 for the worst case).
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt>
+to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
+
+<p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt>
+to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
+
+<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt>
+to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
+
+<p><i>[Matt provided wording]</i></p>
+<p><b>Rationale:</b></p>
+<p>The LWG considered just saying <i>O</i>(log n) for all three, but
+Ê decided that threw away too much valuable information.Ê The fact
+Ê that lower_bound is twice as fast as equal_range is important.
+Ê However, it's better to allow an arbitrary additive constant than to
+Ê specify an exact count.Ê An exact count would have to
+Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to
+Ê get this wrong, and don't provide any substantial value for users.</p>
+<hr>
 <a name="386"><h3>386.&nbsp;Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b>&nbsp;24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
 <p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt> 
 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
@@ -13216,7 +13650,7 @@ In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-ios
 of <tt>sentry::operator bool()</tt> to const.
 </p>
 <hr>
-<a name="443"></a><h3><a name="443">443.&nbsp;filebuf::close() inconsistent use of EOF</a></h3><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
+<a name="443"><h3>443.&nbsp;filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
 <p>
 In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of
 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
@@ -13888,6 +14322,194 @@ value of widen(c) is otherwise.
 I propose to strike the Footnote.
 </p>
 <hr>
+<a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
+<p>
+It is not clear whether the function object passed to for_each is allowed to
+modify the elements of the sequence being iterated over.
+</p>
+
+<p>
+for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
+Non-modifying sequence operations". 'Non-modifying sequence operation' is
+never defined.
+</p>
+
+<p>
+25(5) says: "If an algorithm's Effects section says that a value pointed to
+by any iterator passed as an argument is modified, then that algorithm has
+an additional type requirement: The type of that argument shall satisfy the
+requirements of a mutable iterator (24.1)."
+</p>
+
+<p>for_each's Effects section does not mention whether arguments can be
+modified:</p>
+
+<blockquote>
+  "Effects: Applies f to the result of dereferencing every iterator in the
+   range [first, last), starting from first and proceeding to last - 1."
+</blockquote>
+
+<p>
+Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
+the sense that neither the algorithms themselves nor the function objects
+passed to the algorithms may modify the sequences or elements in any way.
+This DR affects only for_each.
+</p>
+
+<p>
+We suspect that for_each's classification in "non-modifying sequence
+operations" means that the algorithm itself does not inherently modify the
+sequence or the elements in the sequence, but that the function object
+passed to it may modify the elements it operates on. 
+</p>
+
+<p>
+The original STL document by Stepanov and Lee explicitly prohibited the
+function object from modifying its argument.
+The "obvious" implementation of for_each found in several standard library 
+implementations, however, does not impose this restriction.
+As a result, we suspect that the use of for_each with function objects that modify
+their arguments is wide-spread. 
+If the restriction was reinstated, all such code would become non-conforming.
+Further, none of the other algorithms in the Standard
+could serve the purpose of for_each (transform does not guarantee the order in
+which its function object is called). 
+</p>
+
+<p>
+We suggest that the standard be clarified to explicitly allow the function object 
+passed to for_each modify its argument.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If
+the type of 'first' satisfies the requirements of a mutable iterator,
+'f' may apply nonconstant functions through the dereferenced iterators
+passed to it.
+</p>
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes that nothing in the standard prohibits function
+  objects that modify the sequence elements. The problem is that
+  for_each is in a secion entitled "nonmutating algorithms", and the
+  title may be confusing.  A nonnormative note should clarify that.</p>
+<hr>
+<a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
+<p>
+The Forward Iterator requirements table contains the following:
+</p>
+<pre> expression  return type         operational  precondition
+                                  semantics
+  ==========  ==================  ===========  ==========================
+  a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
+              otherwise const U&amp;
+
+  r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
+</pre>
+
+<p>The second line may be unnecessary.  Paragraph 11 of
+  [lib.iterator.requirements] says:
+</p>
+
+<blockquote>
+   In the following sections, a and b denote values of type const X, n
+   denotes a value of the difference type Distance, u, tmp, and m
+   denote identifiers, r denotes a value of X&amp;, t denotes a value of
+   value type T, o denotes a value of some type that is writable to
+   the output iterator.
+</blockquote>
+
+<p>
+Because operators can be overloaded on an iterator's const-ness, the
+current requirements allow iterators to make many of the operations
+specified using the identifiers a and b invalid for non-const
+iterators.</p>
+
+<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
+<p><b>Proposed resolution:</b></p>
+
+<p>Remove the "r-&gt;m" line from the Forward Iterator requirements
+table. Change</p>
+<blockquote>
+    "const X"
+</blockquote>
+
+<p> to </p>
+
+<blockquote>
+    "X or const X" 
+</blockquote>
+
+<p>in paragraph 11 of [lib.iterator.requirements].</p>
+
+
+<p><b>Rationale:</b></p>
+<p>
+This is a defect because it constrains an lvalue to returning a modifiable lvalue.
+</p>
+<hr>
+<a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
+<p>It appears that there are no requirements specified for many of the
+template parameters in clause 22. It looks like this issue has never
+come up, except perhaps for Facet.</p>
+
+<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
+either, which is the wording that allows requirements on template
+parameters to be identified by name.</p>
+
+<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
+changed to cover clause 22. A better change, which will cover us in
+the future, would be to say that it applies to all the library
+clauses. Then if a template gets added to any library clause we are
+covered.</p>
+
+<p>charT, InputIterator, and other names with requirements defined
+elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
+But there are a few template arguments names which I don't think have
+requirements given elsewhere:</p>
+
+<ul>
+<li>internT and externT.  The fix is to add wording saying that internT
+and externT must meet the same requirements as template arguments
+named charT.</li>
+
+<li>stateT.  I'm not sure about this one. There already is some wording,
+but it seems a bit vague.</li>
+
+<li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
+rename "Intl" to "International". The name is important because other
+text identifies the requirements for the name International but not
+for Intl.</li>
+</ul>
+<p><b>Proposed resolution:</b></p>
+<p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p>
+<blockquote>
+The Requirements subclauses may describe names that are used to
+specify constraints on template arguments.153) These names are used in
+clauses 20, 23, 25, and 26 to describe the types that may be supplied
+as arguments by a C++ program when instantiating template components
+from the library. 
+</blockquote>
+<p>to:</p>
+<blockquote>
+The Requirements subclauses may describe names that are used to
+specify constraints on template arguments.153) These names are used in
+library clauses to describe the types that may be supplied as
+arguments by a C++ program when instantiating template components from
+the library.
+</blockquote>
+
+<p>In the front matter of class 22, locales, add:</p>
+<blockquote>
+Template parameter types internT and externT shall meet the
+requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>).
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>
+ Again, a blanket clause isn't blanket enough. Also, we've got a
+ couple of names that we don't have blanket requirement statements
+ for. The only issue is what to do about stateT. This wording is
+ thin, but probably adequate.</p>
+<hr>
 <a name="496"><h3>496.&nbsp;Illegal use of "T" in vector&lt;bool&gt;</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;richard@ex-parrot.com&nbsp; <b>Date:</b>&nbsp;10 Feb 2005</p>
 <p>
 In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>,
@@ -13900,6 +14522,210 @@ the non-template assign() function has the signature</p>
 <p><b>Proposed resolution:</b></p>
 <p>Replace "T" with "value_type".</p>
 <hr>
+<a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
+
+<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
+
+<blockquote>
+<p>static const bool traps;<br>
+-59- true if trapping is implemented for the type.204)
+<br>
+Footnote 204: Required by LIA-1.
+</p>
+</blockquote>
+
+<p>It's not clear what is meant by "is implemented" here.</p>
+
+<p>
+In the context of floating point numbers it seems reasonable to expect
+to be able to use traps to determine whether a program can "safely" use
+infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
+without causing a trap (i.e., on UNIX without having to worry about
+getting a signal). When traps is true, I would expect any of the
+operations in section 7 of IEEE 754 to cause a trap (and my program
+to get a SIGFPE). So, for example, on Alpha, I would expect traps
+to be true by default (unless I compiled my program with the -ieee
+option), false by default on most other popular architectures,
+including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
+traps to be explicitly enabled by the program.
+</p>
+
+<p>
+Another possible interpretation of p59 is that traps should be true
+on any implementation that supports traps regardless of whether they
+are enabled by default or not. I don't think such an interpretation
+makes the traps member very useful, even though that is how traps is
+implemented on several platforms. It is also the only way to implement
+traps on platforms that allow programs to enable and disable trapping
+at runtime.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change p59 to read:</p>
+<blockquote>True if, at program startup, there exists a value of the type that
+  would cause an arithmetic operation using that value to trap.</blockquote>
+<p><b>Rationale:</b></p>
+<p>
+ Real issue, since trapping can be turned on and off. Unclear what a
+ static query can say about a dynamic issue. The real advice we should
+ give users is to use cfenv for these sorts of queries. But this new
+ proposed resolution is at least consistent and slightly better than
+ nothing.</p>
+<hr>
+<a name="505"><h3>505.&nbsp;Result_type in random distribution requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<p>
+Table 17: Random distribution requirements
+</p>
+<p>
+Row 1 requires that each random distribution provide a nested type "input_type";
+this type denotes the type of the values that the distribution consumes.
+</p>
+<p>
+Inspection of all distributions in [tr.rand.dist] reveals that each distribution
+provides a second typedef ("result_type") that denotes the type of the values the
+distribution produces when called.  
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+It seems to me that this is also a requirement
+for all distributions and should therefore be  indicated as such via a new second
+row to this table 17:
+</p>
+<table border="1" cellpadding="5">
+<tbody><tr>
+<td>X::result_type</td>
+<td>T</td>
+<td>---</td>
+<td>compile-time</td>
+</tr>
+</tbody></table>
+
+<p><i>[
+Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
+]</i></p>
+
+<hr>
+<a name="507"><h3>507.&nbsp;Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<p>
+Paragraph 11 of [tr.rand.var] equires that the member template
+</p>
+<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
+</pre></blockquote>
+<p>
+return
+</p>
+<blockquote><pre>distribution()(e, value)
+</pre></blockquote>
+<p>
+However, not all distributions have an operator() with a corresponding signature.
+</p>
+
+<p><i>[
+Berlin:  As a working group we voted in favor of N1932 which makes this moot:
+variate_generator has been eliminated.  Then in full committee we voted to give
+this issue WP status (mistakenly).
+]</i></p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+We therefore  recommend that we insert the following precondition before paragraph 11:
+</p>
+<blockquote>
+Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
+</blockquote>
+<hr>
+<a name="508"><h3>508.&nbsp;Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<p>
+The fifth of these engines with predefined parameters, ranlux64_base_01,
+appears to have an unintentional error for which there is a simple correction.
+The two pre-defined  subtract_with_carry_01 engines are given as: 
+</p>
+<blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
+typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
+</pre></blockquote>
+<p>
+We demonstrate below that ranlux64_base_01 fails to meet the intent of the
+random number generation proposal, but that the simple correction to
+</p>
+<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
+</pre></blockquote>
+<p>
+does meet the intent of defining well-known good parameterizations.
+</p>
+<p>
+The ranlux64_base_01 engine as presented fails to meet the intent for
+predefined engines, stated in proposal N1398 (section E):
+</p>
+<blockquote><p>
+In order to make good random numbers available to a large number of library
+users, this proposal not only defines generic random-number engines, but also
+provides a number of predefined well-known good parameterizations for those.
+</p></blockquote>
+<p>
+The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
+long period and so meets this criterion.  This property makes it suitable for
+use in the excellent discard_block  engines defined subsequently.  The proof
+of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
++ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
+as defined in [tr.rand.eng.sub1]).
+</p>
+<p>
+The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
+For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
+explicit factorization  would be a challenge).  In consequence, while it is
+certainly possible for some seeding states that this engine would have a very
+long period, it is not at all Òwell-knownÓ that this is the case. The intent
+in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
+use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
+but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
+to deliver 48 random bits at a time rather than 24.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+To achieve this intended behavior, the correct template parameteriztion  would be:
+</p>
+<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
+</pre></blockquote>
+<p>
+The sequence of mantissa bits delivered by this is isomorphic (treating each
+double as having the  bits of two floats) to that delivered by ranlux_base_01.
+</p>
+<p>
+<b>References:</b>
+</p>
+<ol>
+<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
+<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
+<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
+</ol>
+
+<p><i>[
+Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
+just above paragraph 5.
+]</i></p>
+
+<hr>
+<a name="519"><h3>519.&nbsp;Data() undocumented</h3></a><p><b>Section:</b>&nbsp;TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
+<p>
+<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new section, after 6.2.2.3:
+</p>
+<blockquote><pre>T*       data()
+const T* data() const;
+</pre></blockquote>
+<p>
+<b>Returns:</b> <tt>elems</tt>.
+</p>
+<p>
+Change 6.2.2.4/2 to:
+</p>
+<blockquote>
+In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
+of <tt>data()</tt> is unspecified.
+</blockquote>
+<hr>
 <a name="533"><h3>533.&nbsp;typo in 2.2.3.10/1</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;9 Nov 2005</p>
 <p>
 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>