2005-10-28 Paolo Carlini <pcarlini@suse.de>

Merged to mainline at revision 105943. git-svn-id: https://gcc.gnu.org/svn/gcc/branches/libstdcxx_so_7-branch@105977 138bc75d-0d04-0410-961f-82ee72b054a4
author: Paolo Carlini <pcarlini@suse.de> 2005-10-29 00:16:38 +0000
committer: Paolo Carlini <pcarlini@suse.de> 2005-10-29 00:16:38 +0000
commit: 70abccfdbd1b39cc5cc84015758f4d346b0a1d2e (patch)
tree: 4d61467c8db924091939f572a0a9181cb3f18772
parent: c6cbde052f4601f1b0fc2a6a9f1b9b7e850d69de (diff)
13 files changed, 1592 insertions, 505 deletions
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index d4a25a179aa..ceea46da626 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,54 @@
+2005-10-28  Paolo Carlini  <pcarlini@suse.de>
+
+	PR libstdc++/24559
+	* include/c_std/std_cwchar.h (wcspbrk): Adjust signature.
+	* testsuite/21_strings/c_strings/wchar_t/24559.cc: New.
+
+2005-10-25  Paolo Carlini  <pcarlini@suse.de>
+
+	* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 39.
+	* docs/html/ext/howto.html: Adjust.
+
+2005-10-21  Paolo Carlini  <pcarlini@suse.de>
+
+	PR libstdc++/24450
+	* config/locale/generic/time_members.h (__timepunct<>::
+	__timepunct(__c_locale, const char*, size_t)): Avoid leaking
+	memory if new throws inside _M_initialize_timepunct.
+	* config/locale/gnu/time_members.h (__timepunct<>::
+	__timepunct(__c_locale, const char*, size_t)): Likewise.
+	* config/locale/gnu/message_members.h (messages<>::
+	messages(__c_locale, const char*, size_t)): Rearrange to
+	avoid memory leaks.
+
+2005-10-19  Paolo Carlini  <pcarlini@suse.de>
+
+	* include/ext/sso_string_base.h (_M_swap): Rewrite.
+
+2005-10-19  Paolo Carlini  <pcarlini@suse.de>
+
+	* include/ext/rc_string_base.h (_S_terminal): Remove.
+	(_M_set_length): Adjust.
+	(_S_max_size): Change to anonymous enum.
+	(_M_max_size()): Add, returns the latter.
+	* include/ext/sso_string_base.h: Likewise.
+	* include/ext/vstring.h (max_size): Adjust.
+
+2005-10-17  Jonathan Wakely  <redi@gcc.gnu.org>
+
+	PR libstdc++/24244
+	* include/tr1/boost_shared_ptr.h (_Sp_counted_base::_Sp_counted_base()):
+	When __GTHREAD_MUTEX_INIT is defined, initialize the mutex.
+
+2005-10-15  Paolo Carlini  <pcarlini@suse.de>
+
+	* include/tr1/functional: Add missing #pragma GCC system_header.
+
+2005-10-14  Paolo Carlini  <pcarlini@suse.de>
+
+	* include/tr1/hashtable (hashtable::m_erase): Rename to erase_node.
+	(hashtable::erase(iterator), erase(const_iterator)): Adjust.
+
 2005-10-13  Richard Earnshaw  <richard.earnsahw@arm.com>
 
 	PR libstdc++/23926
diff --git a/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch b/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch
index b4b42703807..e26806d66b3 100644
--- a/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch
+++ b/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch
@@ -1,3 +1,7 @@
+2005-10-28  Paolo Carlini  <pcarlini@suse.de>
+
+	Merged to mainline at revision 105943.
+
 2005-10-19  Paolo Carlini  <pcarlini@suse.de>
 
 	* include/ext/sso_string.h (_M_swap): Rewrite.
diff --git a/libstdc++-v3/config/locale/generic/time_members.h b/libstdc++-v3/config/locale/generic/time_members.h
index deea0c8fedd..b3112dc4e37 100644
--- a/libstdc++-v3/config/locale/generic/time_members.h
+++ b/libstdc++-v3/config/locale/generic/time_members.h
@@ -1,6 +1,6 @@
 // std::time_get, std::time_put implementation, generic version -*- C++ -*-
 
-// Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
+// Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -55,10 +55,18 @@
 				     size_t __refs) 
     : facet(__refs), _M_data(NULL)
     { 
-      char* __tmp = new char[std::strlen(__s) + 1];
-      std::strcpy(__tmp, __s);
+      const size_t __len = std::strlen(__s) + 1;
+      char* __tmp = new char[__len];
+      std::memcpy(__tmp, __s, __len);
       _M_name_timepunct = __tmp;
-      _M_initialize_timepunct(__cloc); 
+
+      try
+	{ _M_initialize_timepunct(__cloc); }
+      catch(...)
+	{ 
+	  delete [] _M_name_timepunct;
+	  __throw_exception_again;
+	}
     }
 
   template<typename _CharT>
diff --git a/libstdc++-v3/config/locale/gnu/messages_members.h b/libstdc++-v3/config/locale/gnu/messages_members.h
index 92081e3e376..5fb7a999da0 100644
--- a/libstdc++-v3/config/locale/gnu/messages_members.h
+++ b/libstdc++-v3/config/locale/gnu/messages_members.h
@@ -1,6 +1,6 @@
 // std::messages implementation details, GNU version -*- C++ -*-
 
-// Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+// Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -37,18 +37,21 @@
   template<typename _CharT>
      messages<_CharT>::messages(size_t __refs)
      : facet(__refs), _M_c_locale_messages(_S_get_c_locale()), 
-     _M_name_messages(_S_get_c_name())
+       _M_name_messages(_S_get_c_name())
      { }
 
   template<typename _CharT>
      messages<_CharT>::messages(__c_locale __cloc, const char* __s, 
 				size_t __refs) 
-     : facet(__refs), _M_c_locale_messages(_S_clone_c_locale(__cloc)),
-     _M_name_messages(__s)
+     : facet(__refs), _M_c_locale_messages(NULL), _M_name_messages(NULL)
      {
-       char* __tmp = new char[std::strlen(__s) + 1];
-       std::strcpy(__tmp, __s);
+       const size_t __len = std::strlen(__s) + 1;
+       char* __tmp = new char[__len];
+       std::memcpy(__tmp, __s, __len);
        _M_name_messages = __tmp;
+
+       // Last to avoid leaking memory if new throws.
+       _M_c_locale_messages = _S_clone_c_locale(__cloc);
      }
 
   template<typename _CharT>
diff --git a/libstdc++-v3/config/locale/gnu/time_members.h b/libstdc++-v3/config/locale/gnu/time_members.h
index 37a01ef4793..7014630731e 100644
--- a/libstdc++-v3/config/locale/gnu/time_members.h
+++ b/libstdc++-v3/config/locale/gnu/time_members.h
@@ -1,6 +1,6 @@
 // std::time_get, std::time_put implementation, GNU version -*- C++ -*-
 
-// Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+// Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -37,25 +37,33 @@
   template<typename _CharT>
     __timepunct<_CharT>::__timepunct(size_t __refs) 
     : facet(__refs), _M_data(NULL), _M_c_locale_timepunct(NULL), 
-    _M_name_timepunct(_S_get_c_name())
+      _M_name_timepunct(_S_get_c_name())
     { _M_initialize_timepunct(); }
 
   template<typename _CharT>
     __timepunct<_CharT>::__timepunct(__cache_type* __cache, size_t __refs) 
     : facet(__refs), _M_data(__cache), _M_c_locale_timepunct(NULL), 
-    _M_name_timepunct(_S_get_c_name())
+      _M_name_timepunct(_S_get_c_name())
     { _M_initialize_timepunct(); }
 
   template<typename _CharT>
     __timepunct<_CharT>::__timepunct(__c_locale __cloc, const char* __s,
 				     size_t __refs) 
     : facet(__refs), _M_data(NULL), _M_c_locale_timepunct(NULL), 
-    _M_name_timepunct(__s)
+      _M_name_timepunct(NULL)
     { 
-      char* __tmp = new char[std::strlen(__s) + 1];
-      std::strcpy(__tmp, __s);
+      const size_t __len = std::strlen(__s) + 1;
+      char* __tmp = new char[__len];
+      std::memcpy(__tmp, __s, __len);
       _M_name_timepunct = __tmp;
-      _M_initialize_timepunct(__cloc); 
+
+      try
+	{ _M_initialize_timepunct(__cloc); }
+      catch(...)
+	{
+	  delete [] _M_name_timepunct;
+	  __throw_exception_again;
+	}
     }
 
   template<typename _CharT>
diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html
index 7819b3b7a85..31f372a132f 100644
--- a/libstdc++-v3/docs/html/ext/howto.html
+++ b/libstdc++-v3/docs/html/ext/howto.html
@@ -462,7 +462,7 @@
     <dd>Similar to 118.
     </dd>
 
-    <dt><a href="lwg-active.html#280">280</a>:
+    <dt><a href="lwg-defects.html#280">280</a>:
         <em>Comparison of reverse_iterator to const reverse_iterator</em>
     </dt>
     <dd>Add global functions with two template parameters.
@@ -537,7 +537,7 @@
     <dd>Don't fail if the next pointer is null and newoff is zero.
     </dd>
 
-    <dt><a href="lwg-active.html#464">464</a>:
+    <dt><a href="lwg-defects.html#464">464</a>:
         <em>Suggestion for new member functions in standard containers</em>
     </dt>
     <dd>Add <code>data()</code> to <code>std::vector</code> and
diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html
index e698dc582d6..f5b7662ed72 100644
--- a/libstdc++-v3/docs/html/ext/lwg-active.html
+++ b/libstdc++-v3/docs/html/ext/lwg-active.html
@@ -5,11 +5,11 @@
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N1830=05-0090</td>
+<td align="left">N1908=05-0168</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2005-06-24</td>
+<td align="left">2005-10-23</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -20,7 +20,7 @@
 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Active Issues List (Revision R37)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R39)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
   <ul>
@@ -88,6 +88,21 @@
   directory as the issues list files.  </p>
 <h2>Revision History</h2>
 <ul>
+<li>R39: 
+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 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>
+<li>R38: 
+2005-07-03 pre-Mont Tremblant mailing.
+Merged open TR1 issues in <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#522">522</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
+</li>
 <li>R37: 
 2005-06 mid-term mailing.
 Added new 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#503">503</a>.
@@ -679,7 +694,7 @@ 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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
+<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>
 
@@ -953,73 +968,6 @@ 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="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.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;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
-<p>
-This came from an email from Steve Cleary to Fergus in reference to
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
-this in Toronto and believed it should be a separate issue.  There was
-also some reservations about whether this was a worthwhile problem to
-fix.
-</p>
-
-<p>
-Steve said: "Fixing reverse_iterator. std::reverse_iterator can
-(and should) be changed to preserve these additional
-requirements." He also said in email that it can be done without
-breaking user's code: "If you take a look at my suggested
-solution, reverse_iterator doesn't have to take two parameters; there
-is no danger of breaking existing code, except someone taking the
-address of one of the reverse_iterator global operator functions, and
-I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
-case they have, you can leave the old global functions in as well --
-they won't interfere with the two-template-argument functions.  With
-that, I don't see how <i>any</i> user code could break."
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-<b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
-add/change the following declarations:</p>
-<pre>  A) Add a templated assignment operator, after the same manner
-        as the templated copy constructor, i.e.:
-
-  template &lt; class U &gt;
-  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
-
-  B) Make all global functions (except the operator+) have
-  two template parameters instead of one, that is, for
-  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
-
-       template &lt; class Iterator &gt;
-       typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
-                 const reverse_iterator&lt; Iterator &gt;&amp; x,
-                 const reverse_iterator&lt; Iterator &gt;&amp; y);
-
-  with:
-
-      template &lt; class Iterator1, class Iterator2 &gt;
-      typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
-                 const reverse_iterator &lt; Iterator1 &gt; &amp; x,
-                 const reverse_iterator &lt; Iterator2 &gt; &amp; y);
-</pre>
-<p>
-Also make the addition/changes for these signatures in 
-24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
-</p>
-
-<p><i>[
-Copenhagen: The LWG is concerned that the proposed resolution 
-introduces new overloads.  Experience shows that introducing
-overloads is always risky, and that it would be inappropriate to
-make this change without implementation experience.  It may be
-desirable to provide this feature in a different way.
-]</i></p>
-
-<p><i>[
-Lillehammer: We now have implementation experience, and agree that
-this solution is safe and correct.
-]</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>
 <p>The specification of the for_each algorithm does not have a
 "Requires" section, which means that there are no
@@ -1053,7 +1001,7 @@ algorithm does not say so.
   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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
+<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
@@ -1204,7 +1152,7 @@ with a return type of convertible to <tt>T</tt> and operational semantics of
   iterator redesign]</i></p>
 
 <hr>
-<a name="342"><h3>342.&nbsp;seek and eofbit</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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 2001</p>
+<a name="342"><h3>342.&nbsp;seek and eofbit</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;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 2001</p>
 <p>I think we have a defect.</p>
 
 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
@@ -1291,7 +1239,7 @@ 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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
+<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
@@ -1339,7 +1287,7 @@ as a reinterpret_cast, thus masking the error.
 <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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
+<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
@@ -1407,15 +1355,18 @@ mention of an _instance_ of ios_base::Init in Standard.
 
 <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, dynamic initialization of objects
-later in that translation unit may assume that these stream objects
-have been constructed and destructors may assume that these stream
-objects have not yet been destroyed.
+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
@@ -1432,7 +1383,7 @@ object.</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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
+<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],
@@ -1489,7 +1440,7 @@ erase_if() member function that much greater.
 <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>set</tt> and <tt>map</tt>, <tt>insert</tt>and <tt>erase</tt>
+"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> 
 
@@ -1498,14 +1449,17 @@ erase_if() member function that much greater.
 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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
+<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.
@@ -1653,7 +1607,7 @@ partial can only occur if (from_next != from_end)?
   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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
+<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
@@ -1952,7 +1906,7 @@ functions should be changed as proposed below.
 <p><b>Rationale:</b></p>
 
 <hr>
-<a name="396"></a><h3><a name="396">396.&nbsp;what are characters zero and one</a></h3><p><b>Section:</b>&nbsp;23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</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="396"><h3>396.&nbsp;what are characters zero and one</h3></a><p><b>Section:</b>&nbsp;23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</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>
 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
 having the value of 0 or 1 but there is no definition of what
@@ -3147,7 +3101,7 @@ operational semantics for this column to:
 </code>
 
 <hr>
-<a name="459"><h3>459.&nbsp;Requirement for widening in stage 2 is overspecification</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</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;16 Mar 2004</p>
+<a name="459"></a><h3><a name="459">459.&nbsp;Requirement for widening in stage 2 is overspecification</a></h3><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</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;16 Mar 2004</p>
 <p>When parsing strings of wide-character digits, the standard
   requires the library to widen narrow-character "atoms" and compare
   the widened atoms against the characters that are being parsed.
@@ -3224,95 +3178,6 @@ technique to perform the comparison:</p>
       if it the source and destination types are the same</li>
 </ol>
 <hr>
-<a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.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;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
-<p>
-Template time_get currently contains difficult, if not impossible,
-requirements for do_date_order, do_get_time, and do_get_date. All require
-the implementation to scan a field generated by the %x or %X conversion
-specifier in strftime. Yes, do_date_order can always return no_order, but
-that doesn't help the other functions. The problem is that %x can be
-nearly anything, and it can vary widely with locales. It's horribly
-onerous to have to parse "third sunday after Michaelmas in the year of
-our Lord two thousand and three," but that's what we currently ask of
-do_get_date. More practically, it leads some people to think that if
-%x produces 10.2.04, we should know to look for dots as separators. Still
-not easy.
-</p>
-
-<p>
-Note that this is the <i>opposite</i> effect from the intent stated in the
-footnote earlier in this subclause:
-</p>
-
-<blockquote>
-"In other words, user confirmation is required for reliable parsing of
-user-entered dates and times, but machine-generated formats can be
-parsed reliably. This allows parsers to be aggressive about interpreting
-user variations on standard formats."
-</blockquote>
-
-<p>
-We should give both implementers and users an easier and more reliable
-alternative: provide a (short) list of alternative delimiters and say
-what the default date order is for no_order. For backward compatibility,
-and maximum latitude, we can permit an implementation to parse whatever
-%x or %X generates, but we shouldn't require it.
-</p>
-<p><b>Proposed resolution:</b></p>
-
-<p><b>In the description:</b></p>
-<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
-        ios_base::iostate&amp; err, tm* t) const;
-</pre>
-
-<p>
-2 Effects: Reads characters starting at suntil it has extracted those
-struct tm members, and remaining format characters, used by
-time_put&lt;&gt;::put to produce the format specified by 'X', or until it
-encounters an error or end of sequence.
-</p>
-
-<p><b>change:</b> 'X'</p>
-
-<p><b>to:</b> "%H:%M:%S"</p>
-
-
-<p>Change</p>
-<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
-        ios_base::iostate&amp; err, tm* t) const;
-
-4 Effects: Reads characters starting at s until it has extracted those
-struct tm members, and remaining format characters, used by
-time_put&lt;&gt;::put to produce the format specified by 'x', or until it
-encounters an error.
-</pre>
-
-<p>to</p>
-iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
-        ios_base::iostate&amp; err, tm* t) const;
-
-4 Effects: Reads characters starting at s until it has extracted those
-struct tm members, and remaining format characters, used by
-time_put&lt;&gt;::put to produce one of the following formats, or until it
-encounters an error. The format depends on the value returned by
-date_order() as follows:
-
-        date_order()  format
-
-        no_order      "%m/%d/%y"
-        dmy           "%d/%m/%y"
-        mdy           "%m/%d/%y"
-        ymd           "%y/%m/%d"
-        ydm           "%y/%d/%m"
-
-An implementation may also accept additional implementation-defined formats.
-<pre></pre>
-
-<p><i>[Redmond: agreed that this is a real problem.  The solution is
-  probably to match C99's parsing rules.  Bill provided wording.
-]</i></p>
-
-<hr>
 <a name="462"><h3>462.&nbsp;Destroying objects with static storage duration</h3></a><p><b>Section:</b>&nbsp;3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</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;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
 <p>
 3.6.3 Termination spells out in detail the interleaving of static
@@ -3601,107 +3466,6 @@ from r-value derived to base).
   want to fix auto_ptr for C++-0x, or remove it and replace it with
   move_ptr and unique_ptr.]</i></p>
 <hr>
-<a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</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;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
-
-<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
-<ol>
-<li> add vector&lt;T&gt;::data() member (const and non-const version)
-semantics: if( empty() ) return 0; else return buffer_;</li>
-<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
-<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
-</ol>
-
-<p>Rationale:</p>
-
-<ul>
-<li>To obtain a pointer to the vector's buffer, one must use either
-operator[]() (which can give undefined behavior for empty vectors) or
-at() (which will then throw if the vector is empty). </li>
-<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
-<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
-<li>Neither when the map is const.</li>
-<li>when we want to make sure we don't add an element accidently</li>
-<li>when it should be considered an error if a key is not in the map</li>
-</ul>
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
-  synopsis after "element access" and before "modifiers":</p>
-<pre>  // <i>[lib.vector.data] data access</i>
-  pointer       data();
-  const_pointer data() const;
-</pre>
-
-<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
-<blockquote>
-<p>23.2.4.x <tt>vector</tt> data access</p>
-<pre>   pointer       data();
-   const_pointer data() const;
-</pre>
-<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
-   range.  For a non-empty vector, data() == &amp;front().</p>
-<p><b>Complexity:</b> Constant time.</p>
-<p><b>Throws:</b> Nothing.</p>
-</blockquote>
-
-<p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
-synopsis immediately after the line for operator[]:</p>
-<pre>  T&amp;       at(const key_type&amp; x);
-  const T&amp; at(const key_type&amp; x) const;
-</pre>
-
-<p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
-<blockquote>
-<pre>  T&amp;       at(const key_type&amp; x);
-  const T&amp; at(const key_type&amp; x) const;
-</pre>
-
-<p><b>Returns:</b> A reference to the element whose key is equivalent
-  to x, if such an element is present in the map.</p>
-<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
-
-</blockquote>
-
-<p><b>Rationale:</b></p>
-<p>Neither of these additions provides any new functionality but the
-  LWG agreed that they are convenient, especially for novices.  The
-  exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
-  was chosen to match <tt>vector::at</tt>.</p>
-<hr>
-<a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</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;Steve Clamage&nbsp; <b>Date:</b>&nbsp;3 Jun 2004</p>
-<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
-not_eq for !=.</p>
-
-<p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
-clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
-as the C header &lt;name.h&gt;. In particular, table 12 lists
-&lt;ciso646&gt; as a C++ header.</p>
-
-<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
-&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
-contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
-
-<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
-"Header &lt;iso646.h&gt;" says that the alternative tokens are not
-defined as macros in &lt;ciso646&gt;, but does not mention the contents
-of &lt;iso646.h&gt;.</p>
-
-<p>I don't find any normative text to support C.2.2.2.</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
-  paragraph 6 (the one about functions must be functions):</p> 
-
-<blockquote>
-<p>Identifiers that are keywords or operators in C++ shall not be defined
-as macros in C++ standard library headers. 
-[Footnote:In particular, including the standard header &lt;iso646.h&gt;
-or &lt;ciso646&gt; has no effect. </p>
-</blockquote>
-
-<p><i>[post-Redmond: Steve provided wording.]</i></p>
-
-<hr>
 <a name="466"><h3>466.&nbsp;basic_string ctor should prevent null pointer error</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</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;Daniel Frey&nbsp; <b>Date:</b>&nbsp;10 Jun 2004</p>
 <p>
 Today, my colleagues and me wasted a lot of time. After some time, I
@@ -3731,104 +3495,6 @@ ambiguate any other legal ctors.</p>
   value is a null pointer), at run time, or both.]</i></p>
 
 <hr>
-<a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</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;28 Jun 2004</p>
-
-<p>
-Table 37 describes the requirements on Traits::compare() in terms of
-those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
-to yield the same result as operator&lt;(char, char).
-</p>
-
-<p>
-Most, if not all, implementations of char_traits&lt;char&gt;::compare()
-call memcmp() for efficiency. However, the C standard requires both
-memcmp() and strcmp() to interpret characters under comparison as
-unsigned, regardless of the signedness of char. As a result, all
-these char_traits implementations fail to meet the requirement
-imposed by Table 37 on compare() when char is signed.
-</p>
-
-
-<p>Read email thread starting with c++std-lib-13499 for more. </p>
-<p><b>Proposed resolution:</b></p>
-
-
-<p>Change 21.1.3.1, p6 from</p>
-<blockquote>
-    The two-argument members assign, eq, and lt are defined identically
-    to the built-in operators =, ==, and &lt; respectively.
-</blockquote>
-<p>to</p>
-<blockquote>
-  The two-argument member assign is defined identically to
-  the built-in operator =. The two
-  argument members eq and lt are defined identically to
-  the built-in operators == and &lt; for type unsigned char.
-</blockquote>
-
-<p><i>[Redmond: The LWG agreed with this general direction, but we
-  also need to change <tt>eq</tt> to be consistent with this change.
-  Post-Redmond: Martin provided wording.]</i></p>
-
-<hr>
-<a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</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#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
-
-<p>The program below is required to compile but when run it typically
-produces unexpected results due to the user-defined conversion from
-std::cout or any object derived from basic_ios to void*.
-</p>
-
-<pre>    #include &lt;cassert&gt;
-    #include &lt;iostream&gt;
-
-    int main ()
-    {
-        assert (std::cin.tie () == std::cout);
-        // calls std::cout.ios::operator void*()
-    }
-</pre>
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
-conversion operator to some unspecified type that is guaranteed not
-to be convertible to any other type except for bool (a pointer-to-member
-might be one such suitable type). In addition, make it clear that the
-pointer type need not be a pointer to a complete type and when non-null,
-the value need not be valid.
-</p>
-
-<p>Specifically, change in [lib.ios] the signature of</p>
-<pre>    operator void*() const;
-</pre>
-<p>to</p>
-<pre>    operator unspecified-bool-type() const;
-</pre>
-<p>and change [lib.iostate.flags], p1 from</p>
-<pre>    operator void*() const;
-</pre>
-<p>to</p>
-<pre>operator unspecified-bool-type() const;
-
-     -1- Returns: if fail() then a value that will evaluate false in a
-      boolean context; otherwise a value that will evaluate true in a
-      boolean context. The value type returned shall not be
-      convertible to int.
-
-     -2- [Note: This conversion can be used in contexts where a bool
-      is expected (e.g., an if condition); however, implicit
-      conversions (e.g., to int) that can occur with bool are not
-      allowed, eliminating some sources of user error. One possible
-      implementation choice for this type is pointer-to-member.  - end
-      note]
-</pre>
-
-<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
-<p><i>[Lillehammer: Doug provided revised wording for
-  "unspecified-bool-type".]</i></p> 
-
-<hr>
 <a name="470"><h3>470.&nbsp;accessing containers from their elements' special functions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</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;28 Jun 2004</p>
 
 <p>
@@ -3975,20 +3641,7 @@ 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="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</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;1 Jul 2004</p>
-
-<p>
-I think Footnote 297 is confused. The paragraph it applies to seems
-quite clear in that widen() is only called if the object is not a char
-stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
-value of widen(c) is otherwise.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
+<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.
@@ -4059,7 +3712,7 @@ passed to it.
   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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
+<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>
@@ -4108,6 +3761,10 @@ table. Change</p>
 <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>
@@ -4127,7 +3784,7 @@ table. Change</p>
   to require containers to support types that define their own special
   versions of <tt>operator new</tt>.</p>
 
-<notes>
+<p><i>[
 Lillehammer: A container will definitely never use this overridden
 operator new, but whether it will fail to compile is unclear from the
 standard.  Are containers supposed to use qualified or unqualified
@@ -4137,7 +3794,7 @@ Allocator::construct(). If containers don't use it, the details of how
 containers use placement new are unspecified. That is the real bug,
 but it needs to be fixed as part of the allocator overhaul.  Weak
 support that the eventual solution should make this code well formed.
-</notes>
+]</i></p>
 
 <p><b>Proposed resolution:</b></p>
 <hr>
@@ -4479,7 +4136,7 @@ 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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
+<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>
@@ -4542,19 +4199,7 @@ requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc2
  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#Ready">Ready</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>,
-the non-template assign() function has the signature</p>
-
-<pre>  void assign( size_type n, const T&amp; t );
-</pre>
-
-<p>The type, T, is not defined in this context.</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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
+<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>
 
@@ -4603,7 +4248,7 @@ at runtime.
  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#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Sean Parent, Joe Gottman&nbsp; <b>Date:</b>&nbsp;4 May 2005</p>
+<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>
 Problem:
 The iterator requirements for partition() and stable_partition() [25.2.12]
@@ -4643,6 +4288,21 @@ swaps are done; otherwise at most (last - first) swaps are done. Exactly
 (last - first) applications of the predicate are done. 
 </p></blockquote>
 
+<p><b>Rationale:</b></p>
+Partition is a "foundation" algorithm useful in many contexts (like sorting
+as just one example) - my motivation for extending it to include forward
+iterators is slist - without this extension you can't partition an slist
+(without writing your own partition). Holes like this in the standard
+library weaken the argument for generic programming (ideally I'd be able
+to provide a library that would refine std::partition() to other concepts
+without fear of conflicting with other libraries doing the same - but
+that is a digression). I consider the fact that partition isn't defined
+to work for ForwardIterator a minor embarrassment.
+
+<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
+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>
@@ -4701,19 +4361,6 @@ in the informative paragraph? Or am I missing something obvious?
 <p>
 </p>
 <hr>
-<a name="500"><h3>500.&nbsp;do_length cannot be implemented correctly</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</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;Krzysztof �elechowski&nbsp; <b>Date:</b>&nbsp;24 May 2005</p>
-<ol>
-<li>codecvt::do_length is of type int;</li>
-<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
-<li>ptrdiff_t cannot be cast to an int without data loss.</li>
-</ol>
-<p>
-Contradiction.
-</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,
@@ -4888,5 +4535,933 @@ facet, but several also need to use a codecvt facet and we don't say so.
 <p><b>Proposed resolution:</b></p>
 <p>
 </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>
+<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 ..."
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 5.1.1 [tr.rand.req], Paragraph 2 replace
+</p>
+
+<blockquote>
+... s is a value of integral type, g is an lvalue of a type other than X that
+defines a zero-argument function object returning values of <del>unsigned integral</del> type
+<ins><tt>unsigned long int</tt></ins>,
+...
+</blockquote>
+
+<p>
+In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
+</p>
+
+<blockquote>
+creates an engine with the initial internal state
+determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
+</blockquote>
+
+<p><i>[
+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><b>Rationale:</b></p>
+<p>
+Jens:  Just requiring X(unsigned long) still makes it possible
+for an evil library writer to also supply a X(int) that does something
+unexpected.  The wording above requires that X(s) always performs
+as if X(unsigned long) would have been called.  I believe that is
+sufficient and implements our intentions from Mont Tremblant.  I
+see no additional use in actually requiring a X(unsigned long)
+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"></a><h3><a name="512">512.&nbsp;Seeding subtract_with_carry_01 from a single unsigned long</a></h3><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>
+<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
+flawed in the case where the engine parameter w (also known as word_size)
+exceeds 31 [bits].  The key part of the paragraph reads:
+</p>
+<blockquote>
+sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
+</blockquote>
+<p>
+and so forth. 
+</p>
+<p>
+Since the specified linear congruential engine, lcg, delivers numbers with
+a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
+example, 48, each of the x(i) will be less than 2**-17.  The consequence
+is that roughly the first 400 numbers delivered will be  conspicuously
+close to either zero or one.
+</p>
+<p>
+Unfortunately, this is not an innocuous flaw:  One of the predefined engines
+in [tr.rand.predef],  namely ranlux64_base_01, has w = 48 and would exhibit
+this poor behavior, while the original N1378 proposal states that these
+pre-defined engines are intended to be of "known good properties."
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
+void seed(unsigned long value = 19780503) by
+</p>
+
+<blockquote>
+<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
+case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
+<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
+<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
+sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
+<ins>as if executing</ins>
+
+<blockquote><pre><ins>
+linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
+seed(lcg);
+</ins></pre></blockquote>
+
+<del>to <tt>(<i>lcg</i>(1) � 2<sup>-<i>w</i></sup>) mod 1
+&#8230; (<i>lcg</i>(<i>r</i>) � 2<sup>-<i>w</i></sup>) mod 1</tt>,
+respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
+else sets carry<tt>(-1) = 0</tt>.</del>
+</blockquote>
+
+<p><i>[
+Jens provided revised wording post Mont Tremblant.
+]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>
+Jens: I'm using an explicit type here, because fixing the
+prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a> even
+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>
+<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
+[tr.rand.synopsis] as:
+</p>
+<blockquote><pre>template&lt; class PSRE &gt;
+class engine_traits;
+</pre></blockquote>
+<p>
+This template�s primary purpose would be as an aid to generic programming involving
+pseudo-random number engines.  Given only the facilities described in tr1, it would
+be very difficult to produce any algorithms involving the notion of a generic engine.
+The intent of this proposal is to  provide, via engine_traits&lt;&gt;, sufficient
+descriptive information to allow an algorithm to employ a pseudo-random number engine
+without regard to its exact type, i.e., as a template parameter.
+</p>
+<p>
+For example, today it is not possible to write an efficient generic function that
+requires any specific number of random bits.  More specifically, consider a
+cryptographic application that internally needs 256 bits of randomness per call:
+</p>
+<blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
+void crypto( Eng&amp; e, InIter in, OutIter out );
+</pre></blockquote>
+<p>
+Without knowning the number of bits of randomness produced per call to a provided
+engine, the algorithm has no means of determining how many times to call the engine.
+</p>
+<p>
+In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
+template as: 
+</p>
+<blockquote><pre>template&lt; class PSRE &gt;
+class engine_traits
+{
+  static  std::size_t  bits_of_randomness = 0u;
+  static  std::string  name()  { return "unknown_engine"; }
+  // TODO: other traits here
+};
+</pre></blockquote>
+<p>
+Further, each engine described in [tr.rand.engine] would be accompanied by a
+complete specialization of this new engine_traits template.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+
+</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>
+<p>
+Paragraph 6 says:
+</p>
+<blockquote>
+... obtained by successive invocations of g, ... 
+</blockquote>
+<p>
+We recommend instead:
+</p>
+<blockquote>
+... obtained by taking successive invocations of g mod 2**32, ...
+</blockquote>
+<p>
+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."
+</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>
+<p>
+Issue 371 deals with stability of multiset/multimap under insert and erase
+(i.e. do they preserve the relative order in ranges of equal elements).
+The same issue applies to unordered_multiset and unordered_multimap.
+</p>
+<p><b>Proposed resolution:</b></p>
+<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
+called with a pointer to member data as it's callable object was
+defined to be mem_fn(ptr); when Peter Dimov and I  unified the
+descriptions of the TR1 function objects we hoisted the descriptions
+of return types into the INVOKE pseudo-function and into result_of.
+Unfortunately, we left pointer to member data out of result_of, so
+bind doesn't have any specified behavior when called with a pointer
+to  member data.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><i>[
+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>
+<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:
+</p>
+<blockquote>
+a pointer to member function type with cv-qualifier cv and no arguments;
+the type T1 is cv T* and R is the return type of the pointer to member function;
+</blockquote>
+<p>
+The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
+function. It should be a pointer to the class that T is a pointer to member of.
+Like this:
+</p>
+<blockquote>
+a pointer to a member function R T0::f() cv (where cv represents the member
+function's cv-qualifiers); the type T1 is cv T0*
+</blockquote>
+<p>
+Similarly, bullet item 2 in 2.1.2/4 should be:
+</p>
+<blockquote>
+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>
+<hr>
+<a name="522"></a><h3><a name="522">522.&nbsp;Tuple doesn't define swap</a></h3><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>
+<p>
+Tuple doesn't define swap().  It should.
+</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>
+<p>
+A problem with TR1 regex is currently being discussed on the Boost 
+developers list. It involves the handling of case-insensitive matching 
+of character ranges such as [Z-a]. The proper behavior (according to the 
+ECMAScript standard) is unimplementable given the current specification 
+of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of 
+the TR1 regex proposal, agrees there is a problem. The full discussion 
+can be found at http://lists.boost.org/boost/2005/06/28850.php (first 
+message copied below). We don't have any recommendations as yet.
+</p>
+<p>
+-- Begin original message --
+</p>
+<p>
+The situation of interest is described in the ECMAScript specification
+(ECMA-262), section 15.10.2.15:
+</p>
+<p>
+"Even if the pattern ignores case, the case of the two ends of a range
+is significant in determining which characters belong to the range.
+Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
+e, and f, while the pattern /[E-f]/i matches all upper and lower-case
+ASCII letters as well as the symbols [, \, ], ^, _, and `."
+</p>
+<p>
+A more interesting case is what should happen when doing a
+case-insentitive match on a range such as [Z-a]. It should match z, Z,
+a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
+Boost.Regex (it throws an exception from the regex constructor).
+</p>
+<p>
+The tough pill to swallow is that, given the specification in TR1, I
+don't think there is any effective way to handle this situation.
+According to the spec, case-insensitivity is handled with
+regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
+if they compare equal after both are sent through the translate_nocase
+function. But I don't see any way of using this translation function to
+make character ranges case-insensitive. Consider the difficulty of
+detecting whether "z" is in the range [Z-a]. Applying the transformation
+to "z" has no effect (it is essentially std::tolower). And we're not
+allowed to apply the transformation to the ends of the range, because as
+ECMA-262 says, "the case of the two ends of a range is significant."
+</p>
+<p>
+So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
+is to redefine translate_nocase to return a string_type containing all
+the characters that should compare equal to the specified character. But
+this function is hard to implement for Unicode, and it doesn't play nice
+with the existing ctype facet. What a mess!
+</p>
+<p>
+-- End original message --
+</p>
+
+<p><i>[
+John Maddock adds:
+]</i></p>
+
+<p>
+One small correction, I have since found that ICU's regex package does 
+implement this correctly, using a similar mechanism to the current 
+TR1.Regex.
+</p>
+<p>
+Given an expression [c1-c2] that is compiled as case insensitive it:
+</p>
+<p>
+Enumerates every character in the range c1 to c2 and converts it to it's 
+case folded equivalent.  That case folded character is then used a key to a 
+table of equivalence classes, and each member of the class is added to the 
+list of possible matches supported by the character-class.  This second step 
+isn't possible with our current traits class design, but isn't necessary if 
+the input text is also converted to a case-folded equivalent on the fly.
+</p>
+<p>
+ICU applies similar brute force mechanisms to character classes such as 
+[[:lower:]] and [[:word:]], however these are at least cached, so the impact 
+is less noticeable in this case.
+</p>
+<p>
+Quick and dirty performance comparisons show that expressions such as 
+"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times 
+slower than a "normal" expression).  For an application that uses a lot of 
+regexes this could have a noticeable performance impact.  ICU also has an 
+advantage in that it knows the range of valid characters codes: code points 
+outside that range are assumed not to require enumeration, as they can not 
+be part of any equivalence class.  I presume that if we want the TR1.Regex 
+to work with arbitrarily large character sets enumeration really does become 
+impractical.
+</p>
+<p>
+Finally note that Unicode has:
+</p>
+<p>
+Three cases (upper, lower and title).
+One to many, and many to one case transformations.
+Character that have context sensitive case translations - for example an 
+uppercase sigma has two different lowercase forms  - the form chosen depends 
+on context(is it end of a word or not), a caseless match for an upper case 
+sigma should match either of the lower case forms, which is why case folding 
+is often approximated by tolower(toupper(c)).
+</p>
+<p>
+Probably we need some way to enumerate character equivalence classes, 
+including digraphs (either as a result or an input), and some way to tell 
+whether the next character pair is a valid digraph in the current locale.
+</p>
+<p>
+Hoping this doesn't make this even more complex that it was already,
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="524"><h3>524.&nbsp;regex named character classes and case-insensitivity don't mix</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>
+<p>
+This defect is also being discussed on the Boost developers list. The 
+full discussion can be found here:
+http://lists.boost.org/boost/2005/07/29546.php
+</p>
+<p>
+-- Begin original message --
+</p>
+<p>
+Also, I may have found another issue, closely related to the one under
+discussion. It regards case-insensitive matching of named character
+classes. The regex_traits&lt;&gt; provides two functions for working with
+named char classes: lookup_classname and isctype. To match a char class
+such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
+bitmask. Later, you pass a char and the bitmask to isctype and get a
+bool yes/no answer.
+</p>
+<p>
+But how does case-insensitivity work in this scenario? Suppose we're
+doing a case-insensitive match on [[:lower:]]. It should behave as if it
+were [[:lower:][:upper:]], right? But there doesn't seem to be enough
+smarts in the regex_traits interface to do this.
+</p>
+<p>
+Imagine I write a traits class which recognizes [[:fubar:]], and the
+"fubar" char class happens to be case-sensitive. How is the regex engine
+to know that? And how should it do a case-insensitive match of a
+character against the [[:fubar:]] char class? John, can you confirm this
+is a legitimate problem?
+</p>
+<p>
+I see two options:
+</p>
+<p>
+1) Add a bool icase parameter to lookup_classname. Then,
+lookup_classname( "upper", true ) will know to return lower|upper
+instead of just upper.
+</p>
+<p>
+2) Add a isctype_nocase function
+</p>
+<p>
+I prefer (1) because the extra computation happens at the time the
+pattern is compiled rather than when it is executed.
+</p>
+<p>
+-- End original message --
+</p>
+
+<p>
+For what it's worth, John has also expressed his preference for option 
+(1) above.
+</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>
+<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><b>Proposed resolution:</b></p>
+<hr>
+<a name="526"></a><h3><a name="526">526.&nbsp;Is it undefined if a function in the standard changes in parameters?</a></h3><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>
+<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
+functions, but which can cause problems in some (or all)
+implementations, as they cause the values given to the function to be
+changed in a way not specified in standard (and therefore not coded to
+correctly work). These fall into two similar categories.
+</p>
+
+<p>
+1) Parameters taken by const reference can be changed during execution
+of the function
+</p>
+
+<p>
+Examples:
+</p>
+
+<p>
+Given std::vector&lt;int&gt; v:
+</p>
+<p>
+v.insert(v.begin(), v[2]);
+</p>
+<p>
+v[2] can be changed by moving elements of vector
+</p>
+
+
+<p>
+Given std::list&lt;int&gt; l:
+</p>
+<p>
+l.remove(*l.begin());
+</p>
+<p>
+Will delete the first element, and then continue trying to access it.
+This is particularily vicious, as it will appear to work in almost all
+cases.
+</p>
+
+<p>
+2) A range is given which changes during the execution of the function:
+Similarly,
+</p>
+
+<p>
+v.insert(v.begin(), v.begin()+4, v.begin()+6);
+</p>
+
+<p>
+This kind of problem has been partly covered in some cases. For example
+std::copy(first, last, result) states that result cannot be in the range
+[first, last). However, does this cover the case where result is a
+reverse_iterator built from some iterator in the range [first, last)?
+Also, std::copy would still break if result was reverse_iterator(last +
+1), yet this is not forbidden by the standard
+</p>
+
+<p>
+Solution:
+</p>
+
+<p>
+One option would be to try to more carefully limit the requirements of
+each function. There are many functions which would have to be checked.
+However as has been shown in the std::copy case, this may be difficult.
+A simpler, more global option would be to somewhere insert text similar to:
+</p>
+
+<p>
+If the execution of any function would change either any values passed
+by reference or any value in any range passed to a function in a way not
+defined in the definition of that function, the result is undefined.
+</p>
+
+<p>
+Such code would have to at least cover chapters 23 and 25 (the sections
+I read through carefully). I can see no harm on applying it to much of
+the rest of the standard.
+</p>
+
+<p>
+Some existing parts of the standard could be improved to fit with this,
+for example the requires for 25.2.1 (Copy) could be adjusted to:
+</p>
+
+<p>
+Requires: For each non-negative integer n &lt; (last - first), assigning to
+*(result + n) must not alter any value in the range [first + n, last).
+</p>
+
+<p>
+However, this may add excessive complication.
+</p>
+
+<p>
+One other benefit of clearly introducing this text is that it would
+allow a number of small optimisations, such as caching values passed
+by const reference.
+</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>
+<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
+don't.
+</p>
+
+<p>
+This guarantee is not present in the final version of TR1.
+</p>
+
+<p>
+I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
+</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>
+<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
+unordered_multiset:
+</p>
+
+<blockquote>
+    "The iterator and const_iterator types are both const types. It is
+unspecified whether they are the same type"
+</blockquote>
+
+<p>
+Now, according to the resolution of 6.19, we have overloads of insert
+with hint and erase (single and range) both for iterator and
+const_iterator, which, AFAICS, can be meaningful at the same time *only*
+if iterator and const_iterator *are* in fact different types.
+</p>
+<p>
+Then, iterator and const_iterator are *required* to be different types?
+Or that is an unintended consequence? Maybe the overloads for plain
+iterators should be added only to unordered_map and unordered_multimap?
+Or, of course, I'm missing something?
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 6.3.4.3p2 (and 6.3.4.5p2):
+</p>
+<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>
+</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 f7ff410c01d..380c85e70e6 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -5,11 +5,11 @@
 <table>
 <tbody><tr>
 <td align="left">Doc. no.</td>
-<td align="left">N1831=05-0091</td>
+<td align="left">N1909=05-0169</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">2005-06-24</td>
+<td align="left">2005-10-23</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -20,7 +20,7 @@
 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
 </tr>
 </tbody></table>
-<h1>C++ Standard Library Defect Report List (Revision R37)</h1>
+<h1>C++ Standard Library Defect Report List (Revision R39)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
     <ul>
@@ -42,6 +42,21 @@
   document.</p>
 <h2>Revision History</h2>
 <ul>
+<li>R39: 
+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 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>
+<li>R38: 
+2005-07-03 pre-Mont Tremblant mailing.
+Merged open TR1 issues in <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#522">522</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
+</li>
 <li>R37: 
 2005-06 mid-term mailing.
 Added new 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#503">503</a>.
@@ -627,7 +642,7 @@ list maintainer's note: the IS is the same.]</p>
 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 supporting to the proposed resolution.</p>
 <hr>
-<a name="11"></a><h3><a name="11">11.&nbsp;Bitset minor problems</a></h3><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
+<a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 not documented in 23.3.5.2. </p>
 
@@ -680,7 +695,7 @@ it's undefined. </p>
 <p>In 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
 "charT()"</p>
 <hr>
-<a name="14"></a><h3><a name="14">14.&nbsp;Locale::combine should be const</a></h3><p><b>Section:</b>&nbsp;22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<a name="14"><h3>14.&nbsp;Locale::combine should be const</h3></a><p><b>Section:</b>&nbsp;22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>locale::combine is the only member function of locale (other than constructors and
 destructor) that is not const. There is no reason for it not to be const, and good reasons
 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
@@ -879,7 +894,7 @@ one case.  The resolution of this issue clarifies what the LWG
 believes to have been the original intent.</p>
 
 <hr>
-<a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<a name="24"></a><h3><a name="24">24.&nbsp;"do_convert" doesn't exist</a></h3><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 symbol "do_convert" which is not defined in the
 standard. This is a leftover from an edit, and should be "do_in
@@ -889,7 +904,7 @@ and do_out". </p>
 "do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
 or do_out". </p>
 <hr>
-<a name="25"></a><h3><a name="25">25.&nbsp;String operator&lt;&lt; uses width() value wrong</a></h3><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<a name="25"><h3>25.&nbsp;String operator&lt;&lt; uses width() value wrong</h3></a><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
@@ -2368,7 +2383,7 @@ item from:</p>
   extracted.
 </blockquote>
 <hr>
-<a name="69"></a><h3><a name="69">69.&nbsp;Must elements of a vector be contiguous?</a></h3><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
+<a name="69"><h3>69.&nbsp;Must elements of a vector be contiguous?</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
 
 <p>(Please note that this is entirely separate from the question of
@@ -2737,7 +2752,7 @@ returning eof or by throwing an exception; there are no other
 possibilities.  The proposed resolution makes it clear that these two
 functions do get characters from a streambuf.</p>
 <hr>
-<a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</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;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
+<a name="92"></a><h3><a name="92">92.&nbsp;Incomplete Algorithm Requirements</a></h3><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</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;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>The standard does not state, how often a function object is copied,
 called, or the order of calls inside an algorithm. This may lead to
 surprising/buggy behavior. Consider the following example: </p>
@@ -2869,7 +2884,7 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
    of input iterators, we can't impose any requirements in the Input
    Iterator requirements table that forward iterators don't satisfy.</p>
 <hr>
-<a name="103"></a><h3><a name="103">103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</a></h3><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.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;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
+<a name="103"><h3>103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.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;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 <p>Set::iterator is described as implementation-defined with a
 reference to the container requirement; the container requirement says
 that const_iterator is an iterator pointing to const T and iterator an
@@ -3158,7 +3173,7 @@ reading:</p>
   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
 </blockquote>
 <hr>
-<a name="114"></a><h3><a name="114">114.&nbsp;Placement forms example in error twice</a></h3><p><b>Section:</b>&nbsp;18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
+<a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p><b>Section:</b>&nbsp;18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
 <p>Section 18.4.1.3 contains the following example: </p>
 
 <pre>[Example: This can be useful for constructing an object at a known address:
@@ -3647,7 +3662,7 @@ to return a const char* not a const charT*. </p>
 <tt>do_scan_not()</tt> to return a <tt> const
 charT*</tt>. </p>
 <hr>
-<a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
+<a name="125"></a><h3><a name="125">125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</a></h3><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 <p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is
 declared to return a valarray&lt;T&gt;, but in Section 26.3.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The
 latter appears to be correct. </p>
@@ -4151,7 +4166,7 @@ follows an "all-or-none" rule.</p>
 <p>For inserters, the LWG believes there is no defect; the standard is correct
 as written.</p>
 <hr>
-<a name="147"></a><h3><a name="147">147.&nbsp;Library Intro refers to global functions that aren't global</a></h3><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
+<a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
 <p>The library had many global functions until 17.4.1.1 [lib.contents]
 paragraph 2 was added: </p>
 
@@ -4405,8 +4420,8 @@ be fixed to use <tt>sbumpc()</tt> instead.</p>
 "supplied" with the words "extracted from the
 stream".</p>
 <hr>
-<a name="160"></a><h3><a name="160">160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
-</a></h3><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
+</h3></a><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
 is not defined. Probably, the referred function is
 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
@@ -4567,7 +4582,7 @@ traits class for some arbitrary charT type, and we somehow have to
 deal with a const char*.  There's nothing better to do but fall back
 to char_traits&lt;char&gt;</p>
 <hr>
-<a name="168"></a><h3><a name="168">168.&nbsp;Typo: formatted vs. unformatted</a></h3><p><b>Section:</b>&nbsp;27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<a name="168"><h3>168.&nbsp;Typo: formatted vs. unformatted</h3></a><p><b>Section:</b>&nbsp;27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The first paragraph begins with a descriptions what has to be done
 in <i>formatted</i> output functions. Probably this is a typo and the
 paragraph really want to describe unformatted output functions...</p>
@@ -4858,7 +4873,7 @@ the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
 where <tt>X</tt> is a container.  There is no requirement that
 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
 can be mixed.  If mixing them is considered important, that's a
-separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#280">280</a>.)
+separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
 </p>
 <hr>
 <a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
@@ -5896,7 +5911,7 @@ change.
 or change the return to distance(b,a).  The LWG preferred the
 former for consistency.</p>
 <hr>
-<a name="211"></a><h3><a name="211">211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</a></h3><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
+<a name="211"><h3>211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3></a><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
 <p>The description of the stream extraction operator for std::string (section
 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
 the case that the operator fails to extract any characters from the input
@@ -8407,6 +8422,73 @@ the wording.  Dave provided new wording.]</i></p>
   all iterators pointing into the vector.  That doesn't necessarily
   mean they all become singular.</p>
 <hr>
+<a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.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;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
+<p>
+This came from an email from Steve Cleary to Fergus in reference to
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
+this in Toronto and believed it should be a separate issue.  There was
+also some reservations about whether this was a worthwhile problem to
+fix.
+</p>
+
+<p>
+Steve said: "Fixing reverse_iterator. std::reverse_iterator can
+(and should) be changed to preserve these additional
+requirements." He also said in email that it can be done without
+breaking user's code: "If you take a look at my suggested
+solution, reverse_iterator doesn't have to take two parameters; there
+is no danger of breaking existing code, except someone taking the
+address of one of the reverse_iterator global operator functions, and
+I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
+case they have, you can leave the old global functions in as well --
+they won't interfere with the two-template-argument functions.  With
+that, I don't see how <i>any</i> user code could break."
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+<b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
+add/change the following declarations:</p>
+<pre>  A) Add a templated assignment operator, after the same manner
+        as the templated copy constructor, i.e.:
+
+  template &lt; class U &gt;
+  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
+
+  B) Make all global functions (except the operator+) have
+  two template parameters instead of one, that is, for
+  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
+
+       template &lt; class Iterator &gt;
+       typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
+                 const reverse_iterator&lt; Iterator &gt;&amp; x,
+                 const reverse_iterator&lt; Iterator &gt;&amp; y);
+
+  with:
+
+      template &lt; class Iterator1, class Iterator2 &gt;
+      typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
+                 const reverse_iterator &lt; Iterator1 &gt; &amp; x,
+                 const reverse_iterator &lt; Iterator2 &gt; &amp; y);
+</pre>
+<p>
+Also make the addition/changes for these signatures in 
+24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
+</p>
+
+<p><i>[
+Copenhagen: The LWG is concerned that the proposed resolution 
+introduces new overloads.  Experience shows that introducing
+overloads is always risky, and that it would be inappropriate to
+make this change without implementation experience.  It may be
+desirable to provide this feature in a different way.
+]</i></p>
+
+<p><i>[
+Lillehammer: We now have implementation experience, and agree that
+this solution is safe and correct.
+]</i></p>
+
+<hr>
 <a name="281"><h3>281.&nbsp;std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b>&nbsp;25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</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;02 Dec 2000</p>
 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
 requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
@@ -9022,7 +9104,7 @@ list" is excessively vague.]</i></p>
 <p><i>[Post-Cura�ao: Robert Klarer provided new wording.]</i></p>
 
 <hr>
-<a name="301"></a><h3><a name="301">301.&nbsp;basic_string template ctor effects clause omits allocator argument</a></h3><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</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;27 Jan 2001</p>
+<a name="301"><h3>301.&nbsp;basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</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;27 Jan 2001</p>
 <p>
 The effects clause for the basic_string template ctor in 21.3.1, p15
 leaves out the third argument of type Allocator. I believe this to be
@@ -10998,7 +11080,7 @@ key greater than k, or a.end() if such an element is not found.
 <p><i>[Cura�ao: LWG reviewed PR.]</i></p>
 
 <hr>
-<a name="355"><h3>355.&nbsp;Operational semantics for a.back()</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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
+<a name="355"></a><h3><a name="355">355.&nbsp;Operational semantics for a.back()</a></h3><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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
 
 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
 specifies operational semantics for "a.back()" as
@@ -11067,8 +11149,8 @@ LWG would like a new issue opened.]</i></p>
 "*tmp" to "return *tmp;"]</i></p>
 
 <hr>
-<a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
-</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.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;12 Mar 2002</p>
+<a name="358"></a><h3><a name="358">358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
+</a></h3><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.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;12 Mar 2002</p>
 <p>
 I don't think <tt>thousands_sep</tt> is being treated correctly after
 decimal_point has been seen. Since grouping applies only to the
@@ -11350,7 +11432,7 @@ with the following signature:</p>
 <p><b>Rationale:</b></p>
 <p>Fixes an obvious typo.</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>
+<a name="373"></a><h3><a name="373">373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</a></h3><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>
 
 <p>
 In 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> and 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>
@@ -11367,7 +11449,7 @@ In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams
 <p><b>Rationale:</b></p>
 <p>Fixes an obvious typo.</p>
 <hr>
-<a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</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>
+<a name="375"></a><h3><a name="375">375.&nbsp;basic_ios should be ios_base in 27.7.1.3</a></h3><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, Table 91, and paragraph
 14 all contain references to "basic_ios::" which should be
@@ -11449,7 +11531,7 @@ heading Meaning, to "space for more than (to_limit - to) destination
 elements was needed to terminate a sequence given the value of state."
 </p>
 <hr>
-<a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
+<a name="381"></a><h3><a name="381">381.&nbsp;detection of invalid mbstate_t in codecvt</a></h3><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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>
 All but one codecvt member functions that take a state_type argument
 list as one of their preconditions that the state_type argument have
@@ -12023,7 +12105,7 @@ flags.]</i></p>
   of the three fstream class template instead.]</i></p>
 
 <hr>
-<a name="410"></a><h3><a name="410">410.&nbsp;Missing semantics for stack and queue comparison operators</a></h3><p><b>Section:</b>&nbsp;23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</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;7 Jun 2003</p>
+<a name="410"><h3>410.&nbsp;Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b>&nbsp;23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</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;7 Jun 2003</p>
 <p>
 Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> list
 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
@@ -12108,7 +12190,7 @@ set_intersection(), not union() and intersection().
 <p><b>Proposed resolution:</b></p>
 <p>Change that sentence to use the correct names.</p>
 <hr>
-<a name="412"></a><h3><a name="412">412.&nbsp;Typo in 27.4.4.3</a></h3><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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
+<a name="412"><h3>412.&nbsp;Typo in 27.4.4.3</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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
 <p>
 The Effects clause in 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> paragraph 5 says that the
 function only throws if the respective bits are already set prior to
@@ -12774,7 +12856,7 @@ template parameter.</p>
 text.]</i></p>
 
 <hr>
-<a name="438"></a><h3><a name="438">438.&nbsp;Ambiguity in the "do the right thing" clause</a></h3><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#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Oct 2003</p>
+<a name="438"><h3>438.&nbsp;Ambiguity in the "do the right thing" clause</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#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Oct 2003</p>
 
 <p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem
 noticed with statements like:</p>
@@ -13476,6 +13558,294 @@ that it is intended to be callable with one argument.
   void open(const char*s,
             ios_base::openmode mode = ios_base::in|ios_base::out);
 <hr>
+<a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.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;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
+<p>
+Template time_get currently contains difficult, if not impossible,
+requirements for do_date_order, do_get_time, and do_get_date. All require
+the implementation to scan a field generated by the %x or %X conversion
+specifier in strftime. Yes, do_date_order can always return no_order, but
+that doesn't help the other functions. The problem is that %x can be
+nearly anything, and it can vary widely with locales. It's horribly
+onerous to have to parse "third sunday after Michaelmas in the year of
+our Lord two thousand and three," but that's what we currently ask of
+do_get_date. More practically, it leads some people to think that if
+%x produces 10.2.04, we should know to look for dots as separators. Still
+not easy.
+</p>
+
+<p>
+Note that this is the <i>opposite</i> effect from the intent stated in the
+footnote earlier in this subclause:
+</p>
+
+<blockquote>
+"In other words, user confirmation is required for reliable parsing of
+user-entered dates and times, but machine-generated formats can be
+parsed reliably. This allows parsers to be aggressive about interpreting
+user variations on standard formats."
+</blockquote>
+
+<p>
+We should give both implementers and users an easier and more reliable
+alternative: provide a (short) list of alternative delimiters and say
+what the default date order is for no_order. For backward compatibility,
+and maximum latitude, we can permit an implementation to parse whatever
+%x or %X generates, but we shouldn't require it.
+</p>
+<p><b>Proposed resolution:</b></p>
+
+<p><b>In the description:</b></p>
+<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
+        ios_base::iostate&amp; err, tm* t) const;
+</pre>
+
+<p>
+2 Effects: Reads characters starting at suntil it has extracted those
+struct tm members, and remaining format characters, used by
+time_put&lt;&gt;::put to produce the format specified by 'X', or until it
+encounters an error or end of sequence.
+</p>
+
+<p><b>change:</b> 'X'</p>
+
+<p><b>to:</b> "%H:%M:%S"</p>
+
+
+<p>Change</p>
+<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
+        ios_base::iostate&amp; err, tm* t) const;
+
+4 Effects: Reads characters starting at s until it has extracted those
+struct tm members, and remaining format characters, used by
+time_put&lt;&gt;::put to produce the format specified by 'x', or until it
+encounters an error.
+</pre>
+
+<p>to</p>
+iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
+        ios_base::iostate&amp; err, tm* t) const;
+
+4 Effects: Reads characters starting at s until it has extracted those
+struct tm members, and remaining format characters, used by
+time_put&lt;&gt;::put to produce one of the following formats, or until it
+encounters an error. The format depends on the value returned by
+date_order() as follows:
+
+        date_order()  format
+
+        no_order      "%m/%d/%y"
+        dmy           "%d/%m/%y"
+        mdy           "%m/%d/%y"
+        ymd           "%y/%m/%d"
+        ydm           "%y/%d/%m"
+
+An implementation may also accept additional implementation-defined formats.
+<pre></pre>
+
+<p><i>[Redmond: agreed that this is a real problem.  The solution is
+  probably to match C99's parsing rules.  Bill provided wording.
+]</i></p>
+
+<hr>
+<a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</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;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
+
+<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
+<ol>
+<li> add vector&lt;T&gt;::data() member (const and non-const version)
+semantics: if( empty() ) return 0; else return buffer_;</li>
+<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
+<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
+</ol>
+
+<p>Rationale:</p>
+
+<ul>
+<li>To obtain a pointer to the vector's buffer, one must use either
+operator[]() (which can give undefined behavior for empty vectors) or
+at() (which will then throw if the vector is empty). </li>
+<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
+<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
+<li>Neither when the map is const.</li>
+<li>when we want to make sure we don't add an element accidently</li>
+<li>when it should be considered an error if a key is not in the map</li>
+</ul>
+
+<p><b>Proposed resolution:</b></p>
+<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
+  synopsis after "element access" and before "modifiers":</p>
+<pre>  // <i>[lib.vector.data] data access</i>
+  pointer       data();
+  const_pointer data() const;
+</pre>
+
+<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
+<blockquote>
+<p>23.2.4.x <tt>vector</tt> data access</p>
+<pre>   pointer       data();
+   const_pointer data() const;
+</pre>
+<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
+   range.  For a non-empty vector, data() == &amp;front().</p>
+<p><b>Complexity:</b> Constant time.</p>
+<p><b>Throws:</b> Nothing.</p>
+</blockquote>
+
+<p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
+synopsis immediately after the line for operator[]:</p>
+<pre>  T&amp;       at(const key_type&amp; x);
+  const T&amp; at(const key_type&amp; x) const;
+</pre>
+
+<p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
+<blockquote>
+<pre>  T&amp;       at(const key_type&amp; x);
+  const T&amp; at(const key_type&amp; x) const;
+</pre>
+
+<p><b>Returns:</b> A reference to the element whose key is equivalent
+  to x, if such an element is present in the map.</p>
+<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
+
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>Neither of these additions provides any new functionality but the
+  LWG agreed that they are convenient, especially for novices.  The
+  exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
+  was chosen to match <tt>vector::at</tt>.</p>
+<hr>
+<a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</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;Steve Clamage&nbsp; <b>Date:</b>&nbsp;3 Jun 2004</p>
+<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
+not_eq for !=.</p>
+
+<p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
+clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
+as the C header &lt;name.h&gt;. In particular, table 12 lists
+&lt;ciso646&gt; as a C++ header.</p>
+
+<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
+&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
+contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
+
+<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
+"Header &lt;iso646.h&gt;" says that the alternative tokens are not
+defined as macros in &lt;ciso646&gt;, but does not mention the contents
+of &lt;iso646.h&gt;.</p>
+
+<p>I don't find any normative text to support C.2.2.2.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
+  paragraph 6 (the one about functions must be functions):</p> 
+
+<blockquote>
+<p>Identifiers that are keywords or operators in C++ shall not be defined
+as macros in C++ standard library headers. 
+[Footnote:In particular, including the standard header &lt;iso646.h&gt;
+or &lt;ciso646&gt; has no effect. </p>
+</blockquote>
+
+<p><i>[post-Redmond: Steve provided wording.]</i></p>
+
+<hr>
+<a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</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;28 Jun 2004</p>
+
+<p>
+Table 37 describes the requirements on Traits::compare() in terms of
+those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
+to yield the same result as operator&lt;(char, char).
+</p>
+
+<p>
+Most, if not all, implementations of char_traits&lt;char&gt;::compare()
+call memcmp() for efficiency. However, the C standard requires both
+memcmp() and strcmp() to interpret characters under comparison as
+unsigned, regardless of the signedness of char. As a result, all
+these char_traits implementations fail to meet the requirement
+imposed by Table 37 on compare() when char is signed.
+</p>
+
+
+<p>Read email thread starting with c++std-lib-13499 for more. </p>
+<p><b>Proposed resolution:</b></p>
+
+
+<p>Change 21.1.3.1, p6 from</p>
+<blockquote>
+    The two-argument members assign, eq, and lt are defined identically
+    to the built-in operators =, ==, and &lt; respectively.
+</blockquote>
+<p>to</p>
+<blockquote>
+  The two-argument member assign is defined identically to
+  the built-in operator =. The two
+  argument members eq and lt are defined identically to
+  the built-in operators == and &lt; for type unsigned char.
+</blockquote>
+
+<p><i>[Redmond: The LWG agreed with this general direction, but we
+  also need to change <tt>eq</tt> to be consistent with this change.
+  Post-Redmond: Martin provided wording.]</i></p>
+
+<hr>
+<a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
+
+<p>The program below is required to compile but when run it typically
+produces unexpected results due to the user-defined conversion from
+std::cout or any object derived from basic_ios to void*.
+</p>
+
+<pre>    #include &lt;cassert&gt;
+    #include &lt;iostream&gt;
+
+    int main ()
+    {
+        assert (std::cin.tie () == std::cout);
+        // calls std::cout.ios::operator void*()
+    }
+</pre>
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
+conversion operator to some unspecified type that is guaranteed not
+to be convertible to any other type except for bool (a pointer-to-member
+might be one such suitable type). In addition, make it clear that the
+pointer type need not be a pointer to a complete type and when non-null,
+the value need not be valid.
+</p>
+
+<p>Specifically, change in [lib.ios] the signature of</p>
+<pre>    operator void*() const;
+</pre>
+<p>to</p>
+<pre>    operator unspecified-bool-type() const;
+</pre>
+<p>and change [lib.iostate.flags], p1 from</p>
+<pre>    operator void*() const;
+</pre>
+<p>to</p>
+<pre>operator unspecified-bool-type() const;
+
+     -1- Returns: if fail() then a value that will evaluate false in a
+      boolean context; otherwise a value that will evaluate true in a
+      boolean context. The value type returned shall not be
+      convertible to int.
+
+     -2- [Note: This conversion can be used in contexts where a bool
+      is expected (e.g., an if condition); however, implicit
+      conversions (e.g., to int) that can occur with bool are not
+      allowed, eliminating some sources of user error. One possible
+      implementation choice for this type is pointer-to-member.  - end
+      note]
+</pre>
+
+<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
+<p><i>[Lillehammer: Doug provided revised wording for
+  "unspecified-bool-type".]</i></p> 
+
+<hr>
 <a name="469"><h3>469.&nbsp;vector&lt;bool&gt; ill-formed relational operators</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#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
 
 <p>
@@ -13491,5 +13861,30 @@ in c++std-lib-13647).
 Remove all overloads of overloads of relational operators for
 vector&lt;bool&gt; from [lib.vector.bool].
 </p>
+<hr>
+<a name="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</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;1 Jul 2004</p>
+
+<p>
+I think Footnote 297 is confused. The paragraph it applies to seems
+quite clear in that widen() is only called if the object is not a char
+stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
+value of widen(c) is otherwise.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+I propose to strike the Footnote.
+</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>,
+the non-template assign() function has the signature</p>
+
+<pre>  void assign( size_type n, const T&amp; t );
+</pre>
+
+<p>The type, T, is not defined in this context.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Replace "T" with "value_type".</p>
 <p>----- End of document -----</p>
 </body></html>
 \ No newline at end of file
diff --git a/libstdc++-v3/include/c_std/std_cwchar.h b/libstdc++-v3/include/c_std/std_cwchar.h
index 26c4264ef34..9eaaa4ab579 100644
--- a/libstdc++-v3/include/c_std/std_cwchar.h
+++ b/libstdc++-v3/include/c_std/std_cwchar.h
@@ -1,6 +1,6 @@
 // -*- C++ -*- forwarding header.
 
-// Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003
+// Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
 // Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
@@ -211,7 +211,7 @@ namespace std
   using ::wcspbrk;
 
   inline wchar_t*
-  wcspbrk(wchar_t* __s1, wchar_t* __s2)
+  wcspbrk(wchar_t* __s1, const wchar_t* __s2)
   { return wcspbrk(const_cast<const wchar_t*>(__s1), __s2); }
 
   using ::wcsrchr;
diff --git a/libstdc++-v3/include/tr1/boost_shared_ptr.h b/libstdc++-v3/include/tr1/boost_shared_ptr.h
index a998fed2d71..8f95ead7dd5 100644
--- a/libstdc++-v3/include/tr1/boost_shared_ptr.h
+++ b/libstdc++-v3/include/tr1/boost_shared_ptr.h
@@ -101,7 +101,14 @@ public:
 
   _Sp_counted_base()
   : _M_use_count(1), _M_weak_count(1)
-  { }
+  {
+    // For the case of __GTHREAD_MUTEX_INIT we haven't initialised
+    // the mutex yet, so do it now.
+#if defined(__GTHREADS) && defined(__GTHREAD_MUTEX_INIT)
+    __gthread_mutex_t __tmp = __GTHREAD_MUTEX_INIT;
+    _M_mutex = __tmp;
+#endif
+  }
 
   virtual
   ~_Sp_counted_base() // nothrow
diff --git a/libstdc++-v3/include/tr1/functional b/libstdc++-v3/include/tr1/functional
index 76eb87a0bb5..905e6cbfb25 100644
--- a/libstdc++-v3/include/tr1/functional
+++ b/libstdc++-v3/include/tr1/functional
@@ -34,6 +34,8 @@
 #ifndef _TR1_FUNCTIONAL
 #define _TR1_FUNCTIONAL 1
 
+#pragma GCC system_header
+
 #include "../functional"
 #include <typeinfo>
 #include <tr1/type_traits>
diff --git a/libstdc++-v3/include/tr1/hashtable b/libstdc++-v3/include/tr1/hashtable
index 36e33b0f418..0add0e3a966 100644
--- a/libstdc++-v3/include/tr1/hashtable
+++ b/libstdc++-v3/include/tr1/hashtable
@@ -329,7 +329,8 @@ namespace Internal
       { 
 	hashtable_iterator tmp(*this);
 	this->incr();
-	return tmp; }
+	return tmp;
+      }
     };
 
   template<typename Value, bool constant_iterators, bool cache>
@@ -374,7 +375,8 @@ namespace Internal
       { 
 	hashtable_const_iterator tmp(*this);
 	this->incr();
-	return tmp; }
+	return tmp;
+      }
     };
 } // namespace Internal
 
@@ -1169,6 +1171,9 @@ namespace tr1
       iterator
       insert(const value_type&, std::tr1::false_type);
 
+      void
+      erase_node(node*, node**);
+
     public:				// Insert and erase
       Insert_Return_Type
       insert(const value_type& v) 
@@ -1191,25 +1196,21 @@ namespace tr1
 
       iterator
       erase(iterator);
-  
+
       const_iterator
       erase(const_iterator);
- 
+
       size_type
       erase(const key_type&);
 
       iterator
       erase(iterator, iterator);
-	
+
       const_iterator
       erase(const_iterator, const_iterator);
 
       void
       clear();
-      
-    private:
-      // For erase(iterator) and erase(const_iterator).
-      void m_erase(node*, node**);
 
     public:
       // Set number of buckets to be apropriate for container of n element.
@@ -1673,6 +1674,33 @@ namespace tr1
       return iterator(new_node, m_buckets + n);
     }
 
+  // For erase(iterator) and erase(const_iterator).
+  template<typename K, typename V, 
+	   typename A, typename Ex, typename Eq,
+	   typename H1, typename H2, typename H, typename RP,
+	   bool c, bool ci, bool u>
+    void
+    hashtable<K, V, A, Ex, Eq, H1, H2, H, RP, c, ci, u>::
+    erase_node(node* p, node** b)
+    {
+      node* cur = *b;
+      if (cur == p)
+	*b = cur->m_next;
+      else
+	{
+	  node* next = cur->m_next;
+	  while (next != p)
+	    {
+	      cur = next;
+	      next = cur->m_next;
+	    }
+	  cur->m_next = next->m_next;
+	}
+
+      m_deallocate_node (p);
+      --m_element_count;
+    }
+
   template<typename K, typename V, 
 	   typename A, typename Ex, typename Eq,
 	   typename H1, typename H2, typename H, typename RP,
@@ -1702,7 +1730,7 @@ namespace tr1
     {
       iterator result = i;
       ++result;
-      m_erase(i.m_cur_node, i.m_cur_bucket);
+      erase_node(i.m_cur_node, i.m_cur_bucket);
       return result;
     }
   
@@ -1716,7 +1744,7 @@ namespace tr1
     {
       const_iterator result = i;
       ++result;
-      m_erase(i.m_cur_node, i.m_cur_bucket);
+      erase_node(i.m_cur_node, i.m_cur_bucket);
       return result;
     }
 
@@ -1825,32 +1853,6 @@ namespace tr1
 	  __throw_exception_again;
 	}
     }
-
-  template<typename K, typename V, 
-	   typename A, typename Ex, typename Eq,
-	   typename H1, typename H2, typename H, typename RP,
-	   bool c, bool ci, bool u>
-    void
-    hashtable<K, V, A, Ex, Eq, H1, H2, H, RP, c, ci, u>::
-    m_erase(node* p, node** b)
-    {
-      node* cur = *b;
-      if (cur == p)
-	*b = cur->m_next;
-      else
-	{
-	  node* next = cur->m_next;
-	  while (next != p)
-	    {
-	      cur = next;
-	      next = cur->m_next;
-	    }
-	  cur->m_next = next->m_next;
-	}
-
-      m_deallocate_node (p);
-      --m_element_count;
-    }
 }
 }				// Namespace std::tr1
 
diff --git a/libstdc++-v3/testsuite/21_strings/c_strings/wchar_t/24559.cc b/libstdc++-v3/testsuite/21_strings/c_strings/wchar_t/24559.cc
new file mode 100644
index 00000000000..26f03267855
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/c_strings/wchar_t/24559.cc
@@ -0,0 +1,32 @@
+// Copyright (C) 2005 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 2, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING.  If not, write to the Free
+// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+// USA.
+
+// 21.4: null-terminated sequence utilities
+
+#include <cwchar>
+
+// { dg-do compile }
+
+// libstdc++/24559
+int main()
+{
+  typedef wchar_t* (*pf)(wchar_t *, const wchar_t*);
+  pf p1 = std::wcspbrk;
+
+  return 0;
+}
author	Paolo Carlini <pcarlini@suse.de>	2005-10-29 00:16:38 +0000
committer	Paolo Carlini <pcarlini@suse.de>	2005-10-29 00:16:38 +0000
commit	70abccfdbd1b39cc5cc84015758f4d346b0a1d2e (patch)
tree	4d61467c8db924091939f572a0a9181cb3f18772
parent	c6cbde052f4601f1b0fc2a6a9f1b9b7e850d69de (diff)