From aa2d5ba2c737dbc5e0913804d38eb1d0547be33d Mon Sep 17 00:00:00 2001
From: Phil Edwards <pme@gcc.gnu.org>
Date: Sat, 20 Jul 2002 06:26:27 +0000
Subject: abi.txt: New file.

2002-07-20  Phil Edwards  <pme@gcc.gnu.org>

	* docs/html/abi.txt:  New file.
	* docs/html/23_containers/howto.html:  Tweak vector-overhead text.
	* docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html:
	Import from upstream, R22.

	* include/bits/char_traits.h, include/bits/stl_iterator.h,
	include/bits/stl_iterator_base_types.h, libsupc++/exception,
	libsupc++/new, libsupc++/typeinfo:  Use @brief markup.

	* include/bits/deque.tcc, include/bits/stl_alloc.h,
	include/bits/stl_deque.h, include/bits/stl_list.h:  Postpone removal
	of deprecated functions until 3.4.  (Same timeframe, different text.)
	* include/bits/stl_vector.h:  Ditto.  Also do the same cleanups that
	the other sequence classes received.

From-SVN: r55602
---
 libstdc++-v3/docs/html/ext/lwg-active.html  | 2695 ++++++++++++---------------
 libstdc++-v3/docs/html/ext/lwg-defects.html | 1366 +++++++++++++-
 2 files changed, 2538 insertions(+), 1523 deletions(-)

(limited to 'libstdc++-v3/docs/html/ext')

diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html
index 977df96..c8d33f3 100644
--- a/libstdc++-v3/docs/html/ext/lwg-active.html
+++ b/libstdc++-v3/docs/html/ext/lwg-active.html
@@ -5,11 +5,11 @@
 <table>
 <tr>
 <td align="left">Doc. no.</td>
-<td align="left">J16/01-0052 = WG21 N1337</td>
+<td align="left">J16/02-0027 = WG21 N1369</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">09 Nov 2001</td>
+<td align="left">10 May 2002</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -20,7 +20,7 @@
 <td align="left">Matt Austern &lt;austern@research.att.com&gt;</td>
 </tr>
 </table>
-<h1>C++ Standard Library Active Issues List (Revision 20)</h1>
+<h1>C++ Standard Library Active Issues List (Revision 22)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
   <ul>
@@ -88,6 +88,12 @@
   directory as the issues list files.  </p>
 <h2>Revision History</h2>
 <ul>
+<li>R22: 
+Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
+</li>
+<li>R21: 
+Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-active.html#361">361</a>.
+</li>
 <li>R20: 
 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues 
@@ -95,19 +101,19 @@ new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">3
 not discussed at the meeting.  
 
 All Ready issues were moved to DR status, with the exception of issues
-<a href="lwg-active.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.
+<a href="lwg-defects.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.
 
 Noteworthy issues discussed at Redmond include 
 <a href="lwg-active.html#120">120</a> <a href="lwg-active.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>, 
-<a href="lwg-active.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
+<a href="lwg-defects.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
 </li>
 <li>R19: 
 Pre-Redmond mailing.  Added new issues 
-<a href="lwg-active.html#323">323</a>-<a href="lwg-active.html#335">335</a>.
+<a href="lwg-active.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
 </li>
 <li>R18: 
 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-active.html#317">317</a>, and discussed
+Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
 new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
 
 Changed status of issues
@@ -126,7 +132,7 @@ Changed status of issues
 <a href="lwg-defects.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
 <a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
 <a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
-<a href="lwg-defects.html#281">281</a> <a href="lwg-active.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
+<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
 <a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
 <a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
 <a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
@@ -141,8 +147,8 @@ as NAD.
 </li>
 <li>R17: 
 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
-resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-active.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
-Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-active.html#311">311</a>.
+resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
+Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
 </li>
 <li>R16:  
 post-Toronto mailing; reflects actions taken in Toronto. Added new
@@ -188,7 +194,7 @@ of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
 post-Kona mailing: Updated to reflect LWG and full committee actions
 in Kona (99-0048/N1224). Note changed resolution of issues
 <a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
-to <a href="lwg-active.html#198">198</a>. Closed issues list split into &quot;defects&quot; and
+to <a href="lwg-defects.html#198">198</a>. Closed issues list split into &quot;defects&quot; and
 &quot;closed&quot; documents.  Changed the proposed resolution of issue
 <a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 of issue <a href="lwg-defects.html#38">38</a>.
@@ -272,7 +278,7 @@ format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
   <p>
 <b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
   the issue is a duplicate of another issue, and will not be further
-  dealt with. A <b>Rationale</b> identities the duplicated issue's
+  dealt with. A <b>Rationale</b> identifies the duplicated issue's
   issue number.  </p>
 
   <p>
@@ -439,121 +445,8 @@ review of clause 27 as the changes are context sensitive.
 ]</i></p>
 
 <hr>
-<a name="76"><h3>76.&nbsp;Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Sep 1998</p>
-<p>This issue concerns the requirements on classes derived from
-<tt>codecvt</tt>, including user-defined classes. What are the
-restrictions on the conversion from external characters
-(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
-Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
-the I/O library make? </p>
-
-<p>The question is whether it's possible to convert from internal
-characters to external characters one internal character at a time,
-and whether, given a valid sequence of external characters, it's
-possible to pick off internal characters one at a time. Or, to put it
-differently: given a sequence of external characters and the
-corresponding sequence of internal characters, does a position in the
-internal sequence correspond to some position in the external
-sequence? </p>
-
-<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
-sequence of <i>M</i> external characters and that <tt>[ifirst,
-ilast)</tt> is the corresponding sequence of <i>N</i> internal
-characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
-applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
-ilast)</tt>. Now the question: does there necessarily exist a
-subsequence of external characters, <tt>[first, last_1)</tt>, such
-that the corresponding sequence of internal characters is the single
-character <tt>*ifirst</tt>?
-</p>
-
-<p>(What a &quot;no&quot; answer would mean is that
-<tt>my_encoding</tt> translates sequences only as blocks. There's a
-sequence of <i>M</i> external characters that maps to a sequence of
-<i>N</i> internal characters, but that external sequence has no
-subsequence that maps to <i>N-1</i> internal characters.) </p>
-
-<p>Some of the wording in the standard, such as the description of
-<tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
-paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
-possible to pick off internal characters one at a time from a sequence
-of external characters. However, this is never explicitly stated one
-way or the other. </p>
-
-<p>This issue seems (and is) quite technical, but it is important if
-we expect users to provide their own encoding facets. This is an area
-where the standard library calls user-supplied code, so a well-defined
-set of requirements for the user-supplied code is crucial. Users must
-be aware of the assumptions that the library makes. This issue affects
-positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
-and several of <tt>codecvt</tt>'s member functions. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
-
-<blockquote>
-<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
-(27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
-<pre>
-    do_out(state, from, from_end, from_next, to, to_lim, to_next)
-</pre>
-would return <tt>ok</tt>, where <tt>from != from_end</tt>, then 
-<pre>
-    do_out(state, from, from + 1, from_next, to, to_end, to_next)
-</pre>
-must also return <tt>ok</tt>, and that if
-<pre>
-    do_in(state, from, from_end, from_next, to, to_lim, to_next)
-</pre>
-would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
-<pre>
-    do_in(state, from, from_end, from_next, to, to + 1, to_next)
-</pre>
-<p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
-means that <tt>basic_filebuf</tt> assumes that the mapping from
-internal to external characters is 1 to N: a <tt>codecvt</tt> that is
-used by <tt>basic_filebuf</tt> must be able to translate characters
-one internal character at a time.  <i>--End Footnote</i>]</p>
-</blockquote>
-
-<p><i>[Redmond: Minor change in proposed resolution.  Original
-proposed resolution talked about &quot;success&quot;, with a parenthetical
-comment that success meant returning <tt>ok</tt>.  New wording
-removes all talk about &quot;success&quot;, and just talks about the
-return value.]</i></p>
-
-<p><b>Rationale:</b></p>
-
-  <p>The proposed resoluion says that conversions can be performed one
-  internal character at a time.  This rules out some encodings that
-  would otherwise be legal.  The alternative answer would mean there
-  would be some internal positions that do not correspond to any
-  external file position.</p>
-  <p>
-  An example of an encoding that this rules out is one where the
-  <tt>internT</tt> and <tt>externT</tt> are of the same type, and
-  where the internal sequence <tt>c1 c2</tt> corresponds to the
-  external sequence <tt>c2 c1</tt>.
-  </p>
-  <p>It was generally agreed that <tt>basic_filebuf</tt> relies
-  on this property: it was designed under the assumption that
-  the external-to-internal mapping is N-to-1, and it is not clear
-  that <tt>basic_filebuf</tt> is implementable without that 
-  restriction.
-  </p>
-  <p>
-  The proposed resolution is expressed as a restriction on
-  <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
-  than a blanket restriction on all <tt>codecvt</tt> facets,
-  because <tt>basic_filebuf</tt> is the only other part of the 
-  library that uses <tt>codecvt</tt>.  If a user wants to define
-  a <tt>codecvt</tt> facet that implements a more general N-to-M
-  mapping, there is no reason to prohibit it, so long as the user
-  does not expect <tt>basic_filebuf</tt> to be able to use it.
-  </p>
-<hr>
 <a name="91"><h3>91.&nbsp;Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3></a><p>
-<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
+<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>Operator &gt;&gt; and getline() for strings read until eof()
 in the input stream is true. However, this might never happen, if the
 stream can't read anymore without reaching EOF. So shouldn't it be
@@ -604,6 +497,8 @@ should be a formatted input function, not an unformatted input function.
 there is no mechanism for <tt>gcount</tt> to be set except by one of
 <tt>basic_istream</tt>'s member functions.]</i></p>
 
+<p><i>[Cura&ccedil;ao: Nico agrees with proposed resolution.]</i></p>
+
 <p><b>Rationale:</b></p>
 <p>The real issue here is whether or not these string input functions
 get their characters from a streambuf, rather than by calling an
@@ -725,6 +620,9 @@ multiple problems beyond the underlying problem of no definition of
 <p><i>[Post-Tokyo: Nico provided the above proposed
 resolutions.]</i></p>
 
+<p><i>[Cura&ccedil;ao: Nico will provide wording to make options clearer: are
+the exclusive, or is one a superset of the other?]</i></p>
+
 <hr>
 <a name="96"><h3>96.&nbsp;Vector&lt;bool&gt; is not a container</h3></a><p>
 <b>Section:</b>&nbsp;23.2.5 <a href="lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
@@ -810,6 +708,9 @@ how many times a copy constructor is called, even if the copy
 constructor has observable behavior.  (See issue <a href="lwg-active.html#334">334</a>
 for a similar problem.)</p>
 
+<p><i>[Issue still isn't clear.  Matt will try to explain it more
+clearly at the next meeting.]</i></p>
+
 <p><b>Proposed resolution:</b></p>
 <hr>
 <a name="120"><h3>120.&nbsp;Can an implementor add specializations?</h3></a><p>
@@ -881,35 +782,43 @@ different explicit instantiations might be harmless.</p>
   </blockquote>
 </blockquote>
 
-<p><i>[Copenhagen: LWG discussed three options.  (A) Users may not
+<p><i>[Copenhagen: LWG discussed three options.  (1) Users may not
 explicitly instantiate standard library templates, except on
 user-defined types.  Consequence: library implementors may freely
-specialize or instantiate templates.  (B) It is implementation defined
-whether users may explicitly instantiate standard library templates on
-non-user-defined types.  Consequence: library implementors may freely
-specialize or instantiate templates, but may need to document some or
-all templates that have been explicitly instantiated.  (C) Users may
-explicitly instantiate any standard library template.
+specialize or instantiate templates.  (2) Users may explicitly
+instantiate any standard library template.  Consequence: if
+implementors specialize or instantiate library templates, they may
+need to take special steps to make sure users can do it too.  (3) It
+is implementation defined whether users may explicitly instantiate
+standard library templates on non-user-defined types.  Consequence:
+library implementors may freely specialize or instantiate templates,
+but may need to document some or all templates that have been
+explicitly instantiated.
 ]</i></p>
 
-<p><i>[Straw poll (first number is favor, second is strongly oppose):
-A - 4, 0; B - 0, 9; C - 9, 1.  Proposed resolution 1, above, is 
-option A.  (It is the original proposed resolution.)  Proposed 
-resolution 2, above, is option C.  Because there was no support
-for option B, no wording is provided.]</i></p>
+<p><i>[Straw poll (first number is favor, second is strongly oppose): 1
+- 4, 0; 2 - 9, 1; 3 - 0, 9.  (Proposed resolution 1 was the original
+proposed resolution.)  Because there was no support for option 3, no
+wording is provided.]</i></p>
 
 <p><i>[Redmond: discussed again; straw poll had results similar to
-those of Copenhagen (A - 1, 3; B - 6, 2; C - 8, 4).  Most people said
-they could live with any option. The only objection to option A is
+those of Copenhagen (1 - 1, 3; 2 - 8, 4; 3 - 6, 2).  Most people said
+they could live with any option. The only objection to option 2 is
 potential implementation difficulty.  Steve Clamage volunteered do a
-survey to see if there are any popular platforms where option A would
+survey to see if there are any popular platforms where option 2 would
 present a real problem for implementors.  See his reflector message,
 c++std-lib-9002.
 ]</i></p>
 
+<p><i>[Steve and Pete Becker will talk to Jonathan Caves.  The
+Microsoft linker might present a problem if there are multiple copies,
+some of which have static data and some of which are in DLLs.  There
+may be similar problems with the Apple linker; Matt will clarify
+that.]</i></p>
+
 <hr>
 <a name="123"><h3>123.&nbsp;Should valarray helper arrays fill functions be const?</h3></a><p>
-<b>Section:</b>&nbsp;26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
+<b>Section:</b>&nbsp;26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
 <p>One of the operator= in the valarray helper arrays is const and one
 is not. For example, look at slice_array. This operator= in Section
 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
@@ -1098,7 +1007,7 @@ text got garbled when the signed char/unsigned char specializations
 were removed.  Dietmar will provide revised wording.]</i></p>
 <hr>
 <a name="179"><h3>179.&nbsp;Comparison of const_iterators to iterators doesn't work</h3></a><p>
-<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
+<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
 <p>Currently the following will not compile on two well-known standard
 library implementations:</p>
 
@@ -1336,134 +1245,8 @@ function than as an allocator member function.  For the latter,
 it is probably best thought of as an architectural limit.
 Nathan will provide new wording.]</i></p>
 <hr>
-<a name="198"><h3>198.&nbsp;Validity of pointers and references unspecified after iterator destruction</h3></a><p>
-<b>Section:</b>&nbsp;24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Nov 1999</p>
-<p>
-Is a pointer or reference obtained from an iterator still valid after
-destruction of the iterator?
-</p>
-<p>
-Is a pointer or reference obtained from an iterator still valid after the value
-of the iterator changes?
-</p>
-<blockquote>
-<pre>
-#include &lt;iostream&gt;
-#include &lt;vector&gt;
-#include &lt;iterator&gt;
-
-int main()
-{
-    typedef std::vector&lt;int&gt; vec_t;
-    vec_t v;
-    v.push_back( 1 );
-
-    // Is a pointer or reference obtained from an iterator still
-    // valid after destruction of the iterator?
-    int * p = &amp;*v.begin();
-    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
-
-    // Is a pointer or reference obtained from an iterator still
-    // valid after the value of the iterator changes?
-    vec_t::iterator iter( v.begin() );
-    p = &amp;*iter++;
-    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
-
-    return 0;
-}
-</pre>
-</blockquote>
-
-<p>The standard doesn't appear to directly address these
-questions. The standard needs to be clarified. At least two real-world
-cases have been reported where library implementors wasted
-considerable effort because of the lack of clarity in the
-standard. The question is important because requiring pointers and
-references to remain valid has the effect for practical purposes of
-prohibiting iterators from pointing to cached rather than actual
-elements of containers.</p>
-
-<p>The standard itself assumes that pointers and references obtained
-from an iterator are still valid after iterator destruction or
-change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
-effects:</p>
-
-<blockquote>
-  <pre>Iterator tmp = current;
-return *--tmp;</pre>
-</blockquote>
-<p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4 <a href="lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
-<blockquote>
-  <pre>return &amp;(operator*());</pre>
-</blockquote>
-
-<p>Because the standard itself assumes pointers and references remain
-valid after iterator destruction or change, the standard should say so
-explicitly. This will also reduce the chance of user code breaking
-unexpectedly when porting to a different standard library
-implementation.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph to 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
-<blockquote>
-Destruction of an iterator may invalidate pointers and references
-previously obtained from that iterator.
-</blockquote>
-
-<p>Replace paragraph 1 of 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
-
-<blockquote>
-<p><b>Effects:</b></p>
-<pre>
-  this-&gt;tmp = current;
-  --this-&gt;tmp;
-  return *this-&gt;tmp;
-</pre>
-
-<p>
-[<i>Note:</i> This operation must use an auxiliary member variable,
-rather than a temporary variable, to avoid returning a reference that
-persists beyond the lifetime of its associated iterator.  (See
-24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.)  The name of this member variable is shown for
-exposition only.  <i>--end note</i>]
-</p>
-</blockquote>
-
-<p><i>[Post-Tokyo: The issue has been reformulated purely
-in terms of iterators.]</i></p>
-
-<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
-assumption by reverse_iterator. The issue and proposed resolution was
-reformulated yet again to reflect this reality.]</i></p>
-
-<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
-assumes its underlying iterator has persistent pointers and
-references.  Andy Koenig pointed out that it is possible to rewrite
-reverse_iterator so that it no longer makes such an assupmption.
-However, this issue is related to issue <a href="lwg-active.html#299">299</a>.  If we
-decide it is intentional that <tt>p[n]</tt> may return by value
-instead of reference when <tt>p</tt> is a Random Access Iterator,
-other changes in reverse_iterator will be necessary.]</i></p>
-<p><b>Rationale:</b></p>
-<p>This issue has been discussed extensively.  Note that it is
-<i>not</i> an issue about the behavior of predefined iterators.  It is
-asking whether or not user-defined iterators are permitted to have
-transient pointers and references.  Several people presented examples
-of useful user-defined iterators that have such a property; examples
-include a B-tree iterator, and an &quot;iota iterator&quot; that doesn't point
-to memory.  Library implementors already seem to be able to cope with
-such iterators: they take pains to avoid forming references to memory
-that gets iterated past.  The only place where this is a problem is
-<tt>reverse_iterator</tt>, so this issue changes
-<tt>reverse_iterator</tt> to make it work.</p>
-
-<p>This resolution does not weaken any guarantees provided by
-predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
-Clause 23 should be reviewed to make sure that guarantees for
-predefined iterators are as strong as users expect.</p>
-
-<hr>
 <a name="200"><h3>200.&nbsp;Forward iterator requirements don't allow constant iterators</h3></a><p>
-<b>Section:</b>&nbsp;24.1.3 <a href="lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
+<b>Section:</b>&nbsp;24.1.3 <a href="lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
 <p>
 In table 74, the return type of the expression <tt>*a</tt> is given
 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
@@ -1581,7 +1364,7 @@ clear how numeric_limits applies to each of those cases.  A wholesale
 review of numeric_limits is needed.  A paper would be welcome.]</i></p>
 <hr>
 <a name="202"><h3>202.&nbsp;unique() effects unclear when predicate not an equivalence relation</h3></a><p>
-<b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
+<b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
 <p>
 What should unique() do if you give it a predicate that is not an
 equivalence relation?  There are at least two plausible answers:
@@ -1652,7 +1435,7 @@ In fact, the SGI implementation of unique() does neither: It yields 1,
 <blockquote>
 For a nonempty range, eliminates all but the first element from every
 consecutive group of equivalent elements referred to by the iterator
-<tt>i</tt> in the range (first, last) for which the following
+<tt>i</tt> in the range [first+1, last) for which the following
 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
 false</tt>.
 </blockquote>
@@ -1672,6 +1455,11 @@ pointed out that &quot;i-1&quot; is incorrect, since &quot;i&quot; can refer to
 iterator in the range.  Matt provided wording to address this
 problem.]</i></p>
 
+<p><i>[Cura&ccedil;ao: The LWG changed &quot;... the range (first,
+last)...&quot; to &quot;...  the range [first+1, last)...&quot; for
+clarity. They considered this change close enough to editorial to not
+require another round of review.]</i></p>
+
 <p><b>Rationale:</b></p>
 <p>The LWG also considered an alternative resolution: change 
 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
@@ -1795,6 +1583,13 @@ illegal, since, under certain circumstances, its semantics are not
 those specified in the standard.  The standard's description of
 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
 should have any effect.]</i></p>
+
+<p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
+225, 226, and 229.  Their conclusion was that the issues should be
+separated into an LWG portion (Howard will write a proposal), and a
+EWG portion (Dave will write a proposal). The LWG and EWG had
+(separate) discussions of this plan the next day.]</i></p>
+
 <hr>
 <a name="226"><h3>226.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p>
 <b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
@@ -1867,6 +1662,19 @@ similar set of concerns was earlier raised on the boost.org mailing
 list and the ACCU-general mailing list.  Also see library reflector
 message c++std-lib-7354.</p>
 
+<p>
+J. C. van Winkel points out (in c++std-lib-9565) another unexpected
+fact: it's impossible to output a container of std::pair's using copy
+and an ostream_iterator, as long as both pair-members are built-in or
+std:: types.  That's because a user-defined operator&lt;&lt; for (for
+example) std::pair&lt;const std::string, int&gt; will not be found:
+lookup for operator&lt;&lt; will be performed only in namespace std.
+Opinions differed on whether or not this was a defect, and, if so,
+whether the defect is that something is wrong with user-defined
+functionality and std, or whether it's that the standard library does
+not provide an operator&lt;&lt; for std::pair&lt;&gt;.
+</p>
+
 <p><b>Proposed resolution:</b></p>
 
 <p><i>[Tokyo: Summary, &quot;There is no conforming way to extend
@@ -1924,6 +1732,12 @@ unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
 try to put together a proposal before the next meeting.]</i></p>
 
+<p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
+225, 226, and 229.  Their conclusion was that the issues should be
+separated into an LWG portion (Howard will write a proposal), and a
+EWG portion (Dave will write a proposal). The LWG and EWG had
+(separate) discussions of this plan the next day.]</i></p>
+
 <hr>
 <a name="229"><h3>229.&nbsp;Unqualified references of other library entities</h3></a><p>
 <b>Section:</b>&nbsp;17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
@@ -1967,9 +1781,16 @@ are intended to be called by library code.  Several LWG members are
 concerned that valarray appears to require argument-dependent lookup,
 but that the wording may not be clear enough to fall under
 &quot;unless explicitly described otherwise&quot;.]</i></p>
+
+<p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
+225, 226, and 229.  Their conclusion was that the issues should be
+separated into an LWG portion (Howard will write a proposal), and a
+EWG portion (Dave will write a proposal). The LWG and EWG had
+(separate) discussions of this plan the next day.]</i></p>
+
 <hr>
 <a name="231"><h3>231.&nbsp;Precision in iostream?</h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
+<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
 <p>What is the following program supposed to output?</p>
 <pre>#include &lt;iostream&gt;
 
@@ -2025,9 +1846,13 @@ for %f and %e, but not for %g: for %g, precision 0 is taken
 to be the same as precision 1.</p>
 <p>The proposed resolution has the effect that the output of
 the above program will be &quot;1e+00&quot;.</p>
+
+<p><i>[Cura&ccedil;ao: Howard will send Matt improved wording dealing with
+case not covered by current PR.]</i></p>
+
 <hr>
 <a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p>
-<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Apr 2000</p>
+<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Apr 2000</p>
 <p>
 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
@@ -2095,18 +1920,21 @@ t is inserted adjacent to iterator p.
 <p><i>[Toronto: there was general agreement that this is a real defect:
 when inserting an element x into a multiset that already contains
 several copies of x, there is no way to know whether the hint will be
-used.  There was some support for an alternative resolution: we check
-on both sides of the hint (both before and after, in that order).  If
-either is the correct location, the hint is used; otherwise it is not.
-This would be different from the original proposed resolution, because
-in the proposed resolution the hint will be used even if it is very
-far from the insertion point.  JC van Winkel supplied precise wording
-for both options.]</i></p>
-
-<p><i>[Copenhagen: the LWG looked at both options, and preferred the
-original.  This preference is contingent on seeing a reference
+used.  The proposed resolution was that the new element should always
+be inserted as close to the hint as possible.  So, for example, if
+there is a subsequence of equivalent values, then providing a.begin()
+as the hint means that the new element should be inserted before the
+subsequence even if a.begin() is far away.  JC van Winkel supplied
+precise wording for this proposed resolution, and also for an
+alternative resolution in which hints are only used when they are
+adjacent to the insertion point.]</i></p>
+
+<p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
+in which an insertion hint would be used even when it is far from the
+insertion point.  This was contingent on seeing a reference
 implementation showing that it is possible to implement this
-requirement without loss of efficiency.]</i></p>
+requirement without loss of efficiency.  John Potter provided such a
+reference implementation.]</i></p>
 
 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
 emerged from Copenhagen: it seemed excessively complicated, and went
@@ -2117,92 +1945,12 @@ you can do it efficiently enough with a red-black tree, but there are
 other (perhaps better) balanced tree techniques that might differ
 enough to make the detailed semantics hard to satisfy.&quot;]</i></p>
 
-<hr>
-<a name="239"><h3>239.&nbsp;Complexity of unique() and/or unique_copy incorrect</h3></a><p>
-<b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
-<p>The complexity of unique and unique_copy are inconsistent with each
-other and inconsistent with the implementations.&nbsp; The standard
-specifies:</p>
-
-<p>for unique():</p>
-
-<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
-(last - first) - 1 applications of the corresponding predicate, otherwise
-no applications of the predicate.</blockquote>
-
-<p>for unique_copy():</p>
-
-<blockquote>-7- Complexity: Exactly last - first applications of the corresponding
-predicate.</blockquote>
-
-<p>
-The implementations do it the other way round: unique() applies the
-predicate last-first times and unique_copy() applies it last-first-1
-times.</p>
-
-<p>As both algorithms use the predicate for pair-wise comparison of
-sequence elements I don't see a justification for unique_copy()
-applying the predicate last-first times, especially since it is not
-specified to which pair in the sequence the predicate is applied
-twice.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change both complexity sections in 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
-
-<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
-applications of the corresponding predicate.</blockquote>
-
-<hr>
-<a name="240"><h3>240.&nbsp;Complexity of adjacent_find() is meaningless</h3></a><p>
-<b>Section:</b>&nbsp;25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
-<p>The complexity section of adjacent_find is defective:</p>
-
-<blockquote>
-<pre>
-template &lt;class ForwardIterator&gt;
-ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
-                              BinaryPredicate pred);
-</pre>
-
-<p>-1- Returns: The first iterator i such that both i and i + 1 are in
-the range [first, last) for which the following corresponding
-conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
-last if no such iterator is found.</p>
-
-<p>-2- Complexity: Exactly find(first, last, value) - first applications
-of the corresponding predicate.
-</p>
-</blockquote>
-
-<p>In the Complexity section, it is not defined what &quot;value&quot;
-is supposed to mean. My best guess is that &quot;value&quot; means an
-object for which one of the conditions pred(*i,value) or
-pred(value,*i) is true, where i is the iterator defined in the Returns
-section. However, the value type of the input sequence need not be
-equality-comparable and for this reason the term find(first, last,
-value) - first is meaningless.</p>
-
-<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
-find_if(first, last, bind1st(pred,*i)) - first might come closer to
-the intended specification.  Binders can only be applied to function
-objects that have the function call operator declared const, which is
-not required of predicates because they can have non-const data
-members. For this reason, a specification using a binder could only be
-an &quot;as-if&quot; specification.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the complexity section in 25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
-<blockquote>
-For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
-(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
-corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
-return value.
-</blockquote>
-
-<p><i>[Copenhagen: the original resolution specified an upper
-bound.  The LWG preferred an exact count.]</i></p>
+<p><i>[Cura&ccedil;ao: Nathan should give us the alternative wording he
+suggests so the LWG can decide between the two options.]</i></p>
 
 <hr>
 <a name="241"><h3>241.&nbsp;Does unique_copy() require CopyConstructible and Assignable?</h3></a><p>
-<b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
+<b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
 
 <p>Some popular implementations of unique_copy() create temporary
 copies of values in the input sequence, at least if the input iterator
@@ -2231,11 +1979,12 @@ shall not overlap.
 <p>to:</p>
 
 <blockquote>
--4- Requires: The ranges [first, last) and [result, result+(last-first)) 
-shall not overlap. The expression *result = *first must be valid.  If 
-both InputIterator and OutputIterator do not meet the requirements of 
-forward iterator then the value type of InputIterator must be copy 
-constructible.  Otherwise copy constructible is not required.
+  <p>-4- Requires: The ranges [first, last) and [result,
+  result+(last-first)) shall not overlap. The expression *result =
+  *first must be valid. If neither InputIterator nor OutputIterator
+  meets the requirements of forward iterator then the value type of
+  InputIterator must be copy constructible. Otherwise copy
+  constructible is not required. </p>
 </blockquote>
 
 <p><i>[Redmond: the original proposed resolution didn't impose an
@@ -2247,6 +1996,13 @@ it might be possible to implement <tt>unique_copy</tt> without
 requiring assignability, although current implementations do impose
 that requirement.  Howard provided new wording.]</i></p>
 
+<p><i>[
+Cura&ccedil;ao: The LWG changed the PR editorially to specify
+&quot;neither...nor...meet...&quot; as clearer than
+&quot;both...and...do not meet...&quot;. Change believed to be so
+minor as not to require re-review.
+]</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="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
@@ -2319,7 +2075,7 @@ complicated than a while loop whose body is a single-element
 insert.]</i></p>
 <hr>
 <a name="253"><h3>253.&nbsp;valarray helper functions are almost entirely useless</h3></a><p>
-<b>Section:</b>&nbsp;26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
+<b>Section:</b>&nbsp;26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
 <p>This discussion is adapted from message c++std-lib-7056 posted
 November 11, 1999.  I don't think that anyone can reasonably claim
 that the problem described below is NAD.</p>
@@ -2570,7 +2326,9 @@ copy constructor is potentially invoked during stack unwinding.</p>
 
 <p>The copy constructor is a more serious problem, becuase failure
 during stack unwinding invokes <tt>terminate</tt>.  The copy
-constructor must be nothrow.</p>
+constructor must be nothrow. <i>Cura&ccedil;ao: Howard thinks this
+requirement is already present.</i>
+</p>
 
 <p>The fundamental problem is that it's difficult to get the nothrow
 requirement to work well with the requirement that the exception
@@ -2607,6 +2365,8 @@ members thought there was a real defect lurking here.  A small group
 (Herb, Kevlin, Howard, Martin, Dave) will try to make a
 recommendation.]</i></p>
 
+<p><i>[Cura&ccedil;ao: Howard will nag the others to work on a recommendation.]</i></p>
+
 <hr>
 <a name="258"><h3>258.&nbsp;Missing allocator requirement</h3></a><p>
 <b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Aug 2000</p>
@@ -2678,608 +2438,167 @@ 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="270"><h3>270.&nbsp;Binary search requirements overly strict</h3></a><p>
-<b>Section:</b>&nbsp;25.3.3 <a href="lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Oct 2000</p>
-<p>
-Each of the four binary search algorithms (lower_bound, upper_bound,
-equal_range, binary_search) has a form that allows the user to pass a
-comparison function object.  According to 25.3, paragraph 2, that
-comparison function object has to be a strict weak ordering.
-</p>
-
+<a name="278"><h3>278.&nbsp;What does iterator validity mean?</h3></a><p>
+<b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
 <p>
-This requirement is slightly too strict.  Suppose we are searching
-through a sequence containing objects of type X, where X is some
-large record with an integer key.  We might reasonably want to look
-up a record by key, in which case we would want to write something
-like this:
+Section 23.2.2.4 [lib.list.ops] states that
 </p>
 <pre>
-    struct key_comp {
-      bool operator()(const X&amp; x, int n) const {
-        return x.key() &lt; n;
-      }
-    }
-
-    std::lower_bound(first, last, 47, key_comp());
+  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
 </pre>
-
 <p>
-key_comp is not a strict weak ordering, but there is no reason to
-prohibit its use in lower_bound.
+<i>invalidates</i> all iterators and references to list <tt>x</tt>.
 </p>
 
 <p>
-There's no difficulty in implementing lower_bound so that it allows
-the use of something like key_comp.  (It will probably work unless an
-implementor takes special pains to forbid it.)  What's difficult is
-formulating language in the standard to specify what kind of
-comparison function is acceptable.  We need a notion that's slightly
-more general than that of a strict weak ordering, one that can encompass
-a comparison function that involves different types.  Expressing that
-notion may be complicated.
+But what does the C++ Standard mean by &quot;invalidate&quot;?  You
+can still dereference the iterator to a spliced list element, but
+you'd better not use it to delimit a range within the original
+list. For the latter operation, it has definitely lost some of its
+validity.
 </p>
 
-<p><i>Additional questions raised at the Toronto meeting:</i></p>
-<ul>
-<li> Do we really want to specify what ordering the implementor must
-     use when calling the function object?  The standard gives 
-     specific expressions when describing these algorithms, but it also
-     says that other expressions (with different argument order) are
-     equivalent.</li>
-<li> If we are specifying ordering, note that the standard uses both
-     orderings when describing <tt>equal_range</tt>.</li>
-<li> Are we talking about requiring these algorithms to work properly
-     when passed a binary function object whose two argument types
-     are not the same, or are we talking about requirements when
-     they are passed a binary function object with several overloaded
-     versions of <tt>operator()</tt>?</li>
-<li> The definition of a strict weak ordering does not appear to give
-     any guidance on issues of overloading; it only discusses expressions,
-     and all of the values in these expressions are of the same type.
-     Some clarification would seem to be in order.</li>
-</ul>
-
-<p><i>Additional discussion from Copenhagen:</i></p>
-<ul>
-<li>It was generally agreed that there is a real defect here: if
-the predicate is merely required to be a Strict Weak Ordering, then
-it's possible to pass in a function object with an overloaded
-operator(), where the version that's actually called does something
-completely inappropriate.  (Such as returning a random value.)</li>
-
-<li>An alternative formulation was presented in a paper distributed by
-David Abrahams at the meeting, &quot;Binary Search with Heterogeneous
-Comparison&quot;, J16-01/0027 = WG21 N1313: Instead of viewing the
-predicate as a Strict Weak Ordering acting on a sorted sequence, view
-the predicate/value pair as something that partitions a sequence.
-This is almost equivalent to saying that we should view binary search
-as if we are given a unary predicate and a sequence, such that f(*p)
-is true for all p below a specific point and false for all p above it.
-The proposed resolution is based on that alternative formulation.</li>
-</ul>
+<p>
+If we accept the proposed resolution to issue <a href="lwg-defects.html#250">250</a>,
+then we'd better clarify that a &quot;valid&quot; iterator need no
+longer designate an element within the same container as it once did.
+We then have to clarify what we mean by invalidating a past-the-end
+iterator, as when a vector or string grows by reallocation. Clearly,
+such an iterator has a different kind of validity. Perhaps we should
+introduce separate terms for the two kinds of &quot;validity.&quot;
+</p>
 <p><b>Proposed resolution:</b></p>
-
-<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
-
-<blockquote>
-  3 For all algorithms that take Compare, there is a version that uses
-  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
-  *j != false. For the algorithms to work correctly, comp has to
-  induce a strict weak ordering on the values.
-</blockquote>
-
-<p>to:</p>
-
+<p>Add the following text to the end of section 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
+after paragraph 5:</p>
 <blockquote>
-  3 For all algorithms that take Compare, there is a version that uses
-  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
-  &lt; *j != false. For algorithms other than those described in
-  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
-  a strict weak ordering on the values.
+An <i>invalid</i> iterator is an iterator that may be
+singular. [Footnote: This definition applies to pointers, since
+pointers are iterators. The effect of dereferencing an iterator that
+has been invalidated is undefined.]
 </blockquote>
 
-<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
+<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
 
-<blockquote>
-  -6- A sequence [start, finish) is partitioned with respect to an
-  expression f(e) if there exists an integer n such that
-  for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
-  and only if i &lt; n.
-</blockquote>
+<p><i>[Redmond: General agreement with the intent, some objections to
+the wording.  Dave provided new wording.]</i></p>
 
-<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
+<p><i>[Cura&ccedil;ao: The definition of &quot;singular&quot; is
+contentious.&nbsp; The 278 resolution must be made consistent with
+issue <a href="lwg-defects.html#208">208</a> and 24.1/5. Furthermore, a Rationale paragraph
+is required.]</i></p>
 
-<blockquote>
-  -1- All of the algorithms in this section are versions of binary
-   search and assume that the sequence being searched is in order
-   according to the implied or explicit comparison function. They work
-   on non-random access iterators minimizing the number of
-   comparisons, which will be logarithmic for all types of
-   iterators. They are especially appropriate for random access
-   iterators, because these algorithms do a logarithmic number of
-   steps through the data structure. For non-random access iterators
-   they execute a linear number of steps.
-</blockquote>
+<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="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</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="lwg-active.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>to:</p>
+<p>
+Steve said: &quot;Fixing reverse_iterator. std::reverse_iterator can
+(and should) be changed to preserve these additional
+requirements.&quot; He also said in email that it can be done without
+breaking user's code: &quot;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.&quot;
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+<b>Section:</b> 24.4.1.1 <a href="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.:
 
-<blockquote>
-   -1- All of the algorithms in this section are versions of binary
-    search and assume that the sequence being searched is partitioned
-    with respect to an expression formed by binding the search key to
-    an argument of the implied or explicit comparison function. They
-    work on non-random access iterators minimizing the number of
-    comparisons, which will be logarithmic for all types of
-    iterators. They are especially appropriate for random access
-    iterators, because these algorithms do a logarithmic number of
-    steps through the data structure. For non-random access iterators
-    they execute a linear number of steps.
-</blockquote>
+  template &lt; class U &gt;
+  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
 
-<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
+  B) Make all global functions (except the operator+) have
+  two template parameters instead of one, that is, for
+  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
 
-<blockquote>
-   -1- Requires: Type T is LessThanComparable
-    (lib.lessthancomparable). 
-</blockquote>
+       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);
 
-<p>to:</p>
+  with:
 
-<blockquote>
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expression e &lt; value or comp(e, value)
-</blockquote>
+      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="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>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
+<hr>
+<a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p>
+<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
+<p>
+Paragraph 16 mistakenly singles out integral types for inserting 
+thousands_sep() characters.  This conflicts with the syntax for floating 
+point numbers described under 22.2.3.1/2.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change paragraph 16 from:</p>
 
 <blockquote>
-   -2- Effects: Finds the first position into which value can be
-    inserted without violating the ordering. 
+For integral types, punct.thousands_sep() characters are inserted into 
+the sequence as determined by the value returned by punct.do_grouping() 
+using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
 </blockquote>
 
-<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
+<p>To:</p>
 
 <blockquote>
-  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
+For arithmetic types, punct.thousands_sep() characters are inserted into 
+the sequence as determined by the value returned by punct.do_grouping() 
+using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
 </blockquote>
 
-<p>to:</p>
+<p><i>[
+Copenhagen: Opinions were divided about whether this is actually an
+inconsistency, but at best it seems to have been unintentional.  This
+is only an issue for floating-point output: The standard is
+unambiguous that implementations must parse thousands_sep characters
+when performing floating-point.  The standard is also unambiguous that
+this requirement does not apply to the &quot;C&quot; locale.
+]</i></p>
 
-<blockquote>
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expression !(value &lt; e) or !comp(value, e)
-</blockquote>
+<p><i>[
+A survey of existing practice is needed; it is believed that some
+implementations do insert thousands_sep characters for floating-point
+output and others fail to insert thousands_sep characters for 
+floating-point input even though this is unambiguously required by the
+standard.
+]</i></p>
 
-<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
-
-<blockquote>
-   -2- Effects: Finds the furthermost position into which value can be
-    inserted without violating the ordering.
-</blockquote>
-
-<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
-
-<blockquote>
-   -1- Requires: Type T is LessThanComparable
-    (lib.lessthancomparable).
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expressions e &lt; value and !(value &lt; e) or
-   comp(e, value) and !comp(value, e).  Also, for all elements e of
-   [first, last), e &lt; value implies !(value &lt; e) or comp(e,
-   value) implies !comp(value, e)
-</blockquote>
-
-<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
-
-<blockquote>
-   -2- Effects: Finds the largest subrange [i, j) such that the value
-    can be inserted at any iterator k in it without violating the
-    ordering. k satisfies the corresponding conditions: !(*k &lt; value)
-    &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
-    false.
-</blockquote>
-
-<p>to:</p>
-
-<pre>
-   -2- Returns: 
-         make_pair(lower_bound(first, last, value),
-                   upper_bound(first, last, value))
-       or
-         make_pair(lower_bound(first, last, value, comp),
-                   upper_bound(first, last, value, comp))
-</pre>
-
-<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
-
-<blockquote>
-   -1- Requires: Type T is LessThanComparable
-    (lib.lessthancomparable).
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-   -1- Requires: The elements e of [first, last) are partitioned with
-   respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
-   value) and !comp(value, e). Also, for all elements e of [first,
-   last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
-   !comp(value, e)
-</blockquote>
-
-<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
-
-<p><i>[Redmond: Minor changes in wording.  (Removed &quot;non-negative&quot;, and
-changed the &quot;other than those described in&quot; wording.) Also, the LWG
-decided to accept the &quot;optional&quot; part.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>The proposed resolution reinterprets binary search. Instead of
-thinking about searching for a value in a sorted range, we view that
-as an important special case of a more general algorithm: searching
-for the partition point in a partitioned range.</p>
-
-<p>We also add a guarantee that the old wording did not: we ensure
-that the upper bound is no earlier than the lower bound, that
-the pair returned by equal_range is a valid range, and that the first
-part of that pair is the lower bound.</p>
-<hr>
-<a name="274"><h3>274.&nbsp;a missing/impossible allocator requirement</h3></a><p>
-<b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
-<p>
-I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
-any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
-be overloaded on reference and const_reference, which is ill-formed for
-all T = const U. In other words, this won't work:
-</p>
-
-<p>
-template class std::allocator&lt;const int&gt;;
-</p>
-
-<p>
-The obvious solution is to disallow specializations of allocators on
-const types. However, while containers' elements are required to be
-assignable (which rules out specializations on const T's), I think that
-allocators might perhaps be potentially useful for const values in other
-contexts. So if allocators are to allow const types a partial
-specialization of std::allocator&lt;const T&gt; would probably have to be
-provided.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
-
-    <blockquote>
-    any type
-    </blockquote>
-
-<p>to</p>
-    <blockquote>
-    any non-const, non-reference type
-    </blockquote>
-
-<p><i>[Redmond: previous proposed resolution was &quot;any non-const,
-non-volatile, non-reference type&quot;.  Got rid of the &quot;non-volatile&quot;.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>
-Two resolutions were originally proposed: one that partially
-specialized std::allocator for const types, and one that said an
-allocator's value type may not be const.  The LWG chose the second.
-The first wouldn't be appropriate, because allocators are intended for
-use by containers, and const value types don't work in containers.
-Encouraging the use of allocators with const value types would only
-lead to unsafe code.
-</p>
-<p>
-The original text for proposed resolution 2 was modified so that it
-also forbids volatile types and reference types.
-</p>
-<hr>
-<a name="276"><h3>276.&nbsp;Assignable requirement for container value type overly strict</h3></a><p>
-<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
-<p>
-23.1/3 states that the objects stored in a container must be
-Assignable.  23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
-states that map satisfies all requirements for a container, while in
-the same time defining value_type as pair&lt;const Key, T&gt; - a type
-that is not Assignable.
-</p>
-
-<p>
-It should be noted that there exists a valid and non-contradictory
-interpretation of the current text. The wording in 23.1/3 avoids 
-mentioning value_type, referring instead to &quot;objects stored in a
-container.&quot; One might argue that map does not store objects of
-type map::value_type, but of map::mapped_type instead, and that the
-Assignable requirement applies to map::mapped_type, not
-map::value_type.
-</p>
-
-<p>
-However, this makes map a special case (other containers store objects of
-type value_type) and the Assignable requirement is needlessly restrictive in
-general.
-</p>
-
-<p>
-For example, the proposed resolution of active library issue 
-<a href="lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
-means that no set operations can exploit the fact that the stored
-objects are Assignable.
-</p>
-
-<p>
-This is related to, but slightly broader than, closed issue
-<a href="lwg-closed.html#140">140</a>.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>23.1/3: Strike the trailing part of the sentence:</p>
-    <blockquote>
-    , and the additional requirements of Assignable types from 23.1/3
-    </blockquote>
-<p>so that it reads:</p>
-    <blockquote>
-    -3- The type of objects stored in these components must meet the 
-    requirements of CopyConstructible types (lib.copyconstructible).
-    </blockquote>
-
-<p>23.1/4: Modify to make clear that this requirement is not for all 
-containers.  Change to:</p>
-
-<blockquote>
--4- Table 64 defines the Assignable requirement.  Some containers 
-require this property of the types to be stored in the container.  T is 
-the type used to instantiate the container. t is a value of T, and u is 
-a value of (possibly const) T.
-</blockquote>
-
-<p>23.1, Table 65: in the first row, change &quot;T is Assignable&quot; to &quot;T is
-CopyConstructible&quot;.</p>
-
-<p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
-
-<blockquote>
--2- A deque satisfies all of the requirements of a container and of a 
-reversible container (given in tables in lib.container.requirements) and 
-of a sequence, including the optional sequence requirements 
-(lib.sequence.reqmts).  In addition to the requirements on the stored 
-object described in 23.1[lib.container.requirements], the stored object 
-must also meet the requirements of Assignable.  Descriptions are 
-provided here only for operations on deque that are not described in one 
-of these tables or for operations where there is additional semantic 
-information.
-</blockquote>
-
-<p>23.2.2/2:  Add Assignable requirement to specific methods of list.  
-Change to:</p>
-
-<blockquote>
-<p>-2- A list satisfies all of the requirements of a container and of a 
-reversible container (given in two tables in lib.container.requirements) 
-and of a sequence, including most of the the optional sequence 
-requirements (lib.sequence.reqmts). The exceptions are the operator[] 
-and at member functions, which are not provided. 
-
-[Footnote: These member functions are only provided by containers whose 
-iterators are random access iterators. --- end foonote]
-</p>
-
-<p>list does not require the stored type T to be Assignable unless the 
-following methods are instantiated:
-
-[Footnote: Implementors are permitted but not required to take advantage 
-of T's Assignable properties for these methods. -- end foonote]
-</p>
-<pre>
-     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
-     template &lt;class InputIterator&gt;
-       void assign(InputIterator first, InputIterator last);
-     void assign(size_type n, const T&amp; t);
-</pre>
-
-
-<p>Descriptions are provided here only for operations on list that are not 
-described in one of these tables or for operations where there is 
-additional semantic information.</p>
-</blockquote>
-
-<p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
-
-<blockquote>
--2- A vector satisfies all of the requirements of a container and of a 
-reversible container (given in two tables in lib.container.requirements) 
-and of a sequence, including most of the optional sequence requirements 
-(lib.sequence.reqmts). The exceptions are the push_front and pop_front 
-member functions, which are not provided.  In addition to the 
-requirements on the stored object described in 
-23.1[lib.container.requirements], the stored object must also meet the 
-requirements of Assignable.  Descriptions are provided here only for 
-operations on vector that are not described in one of these tables or 
-for operations where there is additional semantic information.
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>list, set, multiset, map, multimap are able to store non-Assignables.
-However, there is some concern about <tt>list&lt;T&gt;</tt>:
-although in general there's no reason for T to be Assignable, some
-implementations of the member functions <tt>operator=</tt> and
-<tt>assign</tt> do rely on that requirement.  The LWG does not want
-to forbid such implementations.</p>
-
-<p>Note that the type stored in a standard container must still satisfy
-the requirements of the container's allocator; this rules out, for
-example, such types as &quot;const int&quot;.  See issue <a href="lwg-active.html#274">274</a>
-for more details.
-</p>
-
-<p>In principle we could also relax the &quot;Assignable&quot; requirement for
-individual <tt>vector</tt> member functions, such as
-<tt>push_back</tt>.  However, the LWG did not see great value in such
-selective relaxation.  Doing so would remove implementors' freedom to
-implement <tt>vector::push_back</tt> in terms of
-<tt>vector::insert</tt>.</p>
-
-<hr>
-<a name="278"><h3>278.&nbsp;What does iterator validity mean?</h3></a><p>
-<b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
-<p>
-Section 23.2.2.4 [lib.list.ops] states that
-</p>
-<pre>
-  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
-</pre>
-<p>
-<i>invalidates</i> all iterators and references to list <tt>x</tt>.
-</p>
-
-<p>
-But what does the C++ Standard mean by &quot;invalidate&quot;?  You
-can still dereference the iterator to a spliced list element, but
-you'd better not use it to delimit a range within the original
-list. For the latter operation, it has definitely lost some of its
-validity.
-</p>
-
-<p>
-If we accept the proposed resolution to issue <a href="lwg-defects.html#250">250</a>,
-then we'd better clarify that a &quot;valid&quot; iterator need no
-longer designate an element within the same container as it once did.
-We then have to clarify what we mean by invalidating a past-the-end
-iterator, as when a vector or string grows by reallocation. Clearly,
-such an iterator has a different kind of validity. Perhaps we should
-introduce separate terms for the two kinds of &quot;validity.&quot;
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of section 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
-after paragraph 5:</p>
-<blockquote>
-An <i>invalid</i> iterator is an iterator that may be
-singular. [Footnote: This definition applies to pointers, since
-pointers are iterators. The effect of dereferencing an iterator that
-has been invalidated is undefined.]
-</blockquote>
-
-<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
-
-<p><i>[Redmond: General agreement with the intent, some objections to
-the wording.  Dave provided new wording.]</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="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</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="lwg-active.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: &quot;Fixing reverse_iterator. std::reverse_iterator can
-(and should) be changed to preserve these additional
-requirements.&quot; He also said in email that it can be done without
-breaking user's code: &quot;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.&quot;
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-<b>Section:</b> 24.4.1.1 <a href="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="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>
-
-<hr>
-<a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
-<p>
-Paragraph 16 mistakenly singles out integral types for inserting 
-thousands_sep() characters.  This conflicts with the syntax for floating 
-point numbers described under 22.2.3.1/2.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change paragraph 16 from:</p>
-
-<blockquote>
-For integral types, punct.thousands_sep() characters are inserted into 
-the sequence as determined by the value returned by punct.do_grouping() 
-using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
-</blockquote>
-
-<p>To:</p>
-
-<blockquote>
-For arithmetic types, punct.thousands_sep() characters are inserted into 
-the sequence as determined by the value returned by punct.do_grouping() 
-using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
-</blockquote>
-
-<p><i>[
-Copenhagen: Opinions were divided about whether this is actually an
-inconsistency, but at best it seems to have been unintentional.  This
-is only an issue for floating-point output: The standard is
-unambiguous that implementations must parse thousands_sep characters
-when performing floating-point.  The standard is also unambiguous that
-this requirement does not apply to the &quot;C&quot; locale.
-]</i></p>
-
-<p><i>[
-A survey of existing practice is needed; it is believed that some
-implementations do insert thousands_sep characters for floating-point
-output and others fail to insert thousands_sep characters for 
-floating-point input even though this is unambiguously required by the
-standard.
-]</i></p>
+<p><i>[Cura&ccedil;ao: Howard will email Bill and other implementors to try to
+move the issue forward.]</i></p>
 
 <hr>
 <a name="283"><h3>283.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p>
-<b>Section:</b>&nbsp;25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
+<b>Section:</b>&nbsp;25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
 <p>
 The requirements in 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>, p1 that <tt>T</tt> to be
 <tt>Assignable</tt> (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) is not necessary or
@@ -3525,54 +2844,11 @@ operand and const T for the right operand. The type
 std::iterator_traits&lt;ForwardIterator&gt;::value_type must be Assignable
 (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>).
 </blockquote>
-
-<hr>
-<a name="284"><h3>284.&nbsp;unportable example in 20.3.7, p6</h3></a><p>
-<b>Section:</b>&nbsp;20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;26 Dec 2000</p>
-<p>The example in 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
-library function <tt>strcmp()</tt> with the function pointer adapter
-<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
-functions have <tt>extern &quot;C&quot;</tt> or <tt>extern
-&quot;C++&quot;</tt> linkage [17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
-function pointers with different the language linkage specifications
-(7.5 <a href="dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
-well-formed is unspecified.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
-<blockquote>
-  <p>[<i>Example:</i>
-</p>
-  <pre>
-    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), &quot;C&quot;)), &quot;C++&quot;);
-  </pre>
-  <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
-</blockquote>
-
-
-<p>to:</p>
-<blockquote>
-  <p>[<i>Example:</i>
-</p>
-  <pre>
-    int compare(const char*, const char*);
-    replace_if(v.begin(), v.end(),
-               not1(bind2nd(ptr_fun(compare), &quot;abc&quot;)), &quot;def&quot;);
-  </pre>
-  <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
-</blockquote>
-
-<p>Also, remove footnote 215 in that same paragraph.</p>
-
-<p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
-issue deals in part with C and C++ linkage, it was believed to be too
-confusing for the strings in the example to be &quot;C&quot; and &quot;C++&quot;.
-]</i></p>
-
-<p><i>[Redmond: More minor changes.  Got rid of the footnote (which
-seems to make a sweeping normative requirement, even though footnotes
-aren't normative), and changed the sentence after the footnote so that
-it corresponds to the new code fragment.]</i></p>
+
+<p><i>[Cura&ccedil;ao: Jeremy reports he has run the changes through his
+automated test tools.  At the request of the LWG, Jeremy will reword
+the PR in terms of valid expressions rather than &quot;equality
+operator&quot;.]</i></p>
 
 <hr>
 <a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p>
@@ -3621,7 +2897,7 @@ blanket statement in Clause 25, not just a special requirement for
 
 <hr>
 <a name="291"><h3>291.&nbsp;Underspecification of set algorithms</h3></a><p>
-<b>Section:</b>&nbsp;25.3.5 <a href="lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
+<b>Section:</b>&nbsp;25.3.5 <a href="lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
 <p>
 The standard library contains four algorithms that compute set
 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
@@ -3671,8 +2947,50 @@ same way.
 </p>
 
 <p><b>Proposed resolution:</b></p>
-<p><i>[The LWG agrees that the standard should answer these questions.
-Matt will provide wording.]</i></p>
+
+<p>Add the following to the end of 25.3.5.2 <a href="lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
+<blockquote>
+If [first1, last1) contains <i>m</i> elements that are equivalent to
+each other and [first2, last2) contains <i>n</i> elements that are
+equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
+will be copied to the output range: all <i>m</i> of these elements
+from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
+[first2, last2), in that order.
+</blockquote>
+
+<p>Add the following to the end of 25.3.5.3 <a href="lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
+<blockquote>
+If [first1, last1) contains <i>m</i> elements that are equivalent to each
+other and [first2, last2) contains <i>n</i> elements that are
+equivalent to them, the first min(<i>m</i>, <i>n</i>) of those 
+elements from [first1, last1) are copied to the output range.
+</blockquote>
+
+<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
+paragraph 4:</p>
+<blockquote>
+If [first1, last1) contains <i>m</i> elements that are equivalent to each
+other and [first2, last2) contains <i>n</i> elements that are
+equivalent to them, the last max(<i>m-n</i>, 0) elements from 
+[first1, last1) are copied to the output range.
+</blockquote>
+
+<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
+paragraph 4:</p>
+<blockquote>
+If [first1, last1) contains <i>m</i> elements that are equivalent to
+each other and [first2, last2) contains <i>n</i> elements that are
+equivalent to them, then |<i>m - n</i>| of those elements will be
+copied to the output range: the last <i>m - n</i> of these elements
+from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
+m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
+</blockquote>
+
+<p><i>[Cura&ccedil;ao: Missing Rationale and missing status comments from
+Redmond made discussion difficult. For union, doesn't the standard
+already say this? Howard, others think maybe so. Several thought the
+PR may be &quot;too complicated&quot;.]</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="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
@@ -3768,6 +3086,8 @@ about issue 299 should keep this possibility in mind.
 <p>In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>, change the return type in table
 76 from &quot;convertible to T&quot; to T&amp;.</p>
 
+<p><i>[Cura&ccedil;ao: Jeremy volunteered to work on this issue.]</i></p>
+
 <hr>
 <a name="300"><h3>300.&nbsp;list::merge() specification incomplete</h3></a><p>
 <b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
@@ -3794,6 +3114,8 @@ Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, &quot;merges the argument list into the
 list&quot; is excessively vague.]</i></p>
 
+<p><i>[Cura&ccedil;ao: Robert Klarer volunteers to work on this issue.]</i></p>
+
 <hr>
 <a name="304"><h3>304.&nbsp;Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p>
 <b>Section:</b>&nbsp;24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;5 Feb 2001</p>
@@ -3834,7 +3156,7 @@ it has no <tt>operator-&gt;</tt>.  A straw poll showed roughly equal
 support for the two options.]</i></p>
 <hr>
 <a name="305"><h3>305.&nbsp;Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
 <p>22.2.1.5/3 introduces codecvt in part with:</p>
 
 <blockquote>
@@ -3939,8 +3261,12 @@ would expect the default encoding to be whatever C uses in the default
 &quot;C&quot; locale.  We could impose a guarantee like the one Nathan suggested
 (a character from the basic execution character set must map to a
 single external character), but this would rule out important
-encodings that are in common use: it would rule out Shift-JIS, for
+encodings that are in common use: it would rule out JIS, for
 example, and it would rule out a fixed-width encoding of UCS-4.</p>
+
+<p><i>[Cura&ccedil;ao: fixed rationale typo at the request of Ichiro Koshida;
+&quot;shift-JIS&quot; changed to &quot;JIS&quot;.]</i></p>
+
 <hr>
 <a name="309"><h3>309.&nbsp;Does sentry catch exceptions?</h3></a><p>
 <b>Section:</b>&nbsp;27.6 <a href="lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;19 Mar 2001</p>
@@ -4045,269 +3371,8 @@ the sentries.
 ]</i></p>
 
 <hr>
-<a name="310"><h3>310.&nbsp;Is errno a macro?</h3></a><p>
-<b>Section:</b>&nbsp;17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
-  <p>
-  Exactly how should errno be declared in a conforming C++ header?
-  </p>
-
-  <p>
-  The C standard says in 7.1.4 that it is unspecified whether errno is a
-  macro or an identifier with external linkage.  In some implementations
-  it can be either, depending on compile-time options.  (E.g., on
-  Solaris in multi-threading mode, errno is a macro that expands to a
-  function call, but is an extern int otherwise.  &quot;Unspecified&quot; allows
-  such variability.)
-  </p>
-
-  <p>The C++ standard:</p>
-  <ul>
-  <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
-  <li>17.4.3.1.3 footnote 166 says errno is reserved as an external 
-      name (true), and implies that it is an identifier.</li>
-  <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
-      on to say that the contents of of C++ &lt;errno.h&gt; are the
-      same as in C, begging the question.</li>
-  <li>C.2, table 95 lists errno as a macro, without comment.</li>
-  </ul>
-
-  <p>I find no other references to errno.</p>
-
-  <p>We should either explicitly say that errno must be a macro, even
-  though it need not be a macro in C, or else explicitly leave it
-  unspecified.  We also need to say something about namespace std. 
-  A user who includes &lt;cerrno&gt; needs to know whether to write
-  <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
-  else &lt;cerrno&gt; is useless.</p>
-
-  <p>Two acceptable fixes:</p>
-  <ul>
-    <li><p>errno must be a macro. This is trivially satisfied by adding<br>
-        &nbsp;&nbsp;#define errno (::std::errno)<br>
-        to the headers if errno is not already a macro. You then always
-        write errno without any scope qualification, and it always expands
-        to a correct reference. Since it is always a macro, you know to
-        avoid using errno as a local identifer.</p></li>
-    <li><p>errno is in the global namespace. This fix is inferior, because
-        ::errno is not guaranteed to be well-formed.</p></li>
-  </ul>
-
-  <p><i>[
-    This issue was first raised in 1999, but it slipped through 
-    the cracks.
-  ]</i></p>
-<p><b>Proposed resolution:</b></p>
-  <p>Change the Note in section 17.4.1.2p5 from</p>
-
-    <blockquote>
-    Note: the names defined as macros in C include the following:
-    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
-    </blockquote>
-
-  <p>to</p>
-
-    <blockquote>
-    Note: the names defined as macros in C include the following:
-    assert, offsetof, setjmp, va_arg, va_end, and va_start.
-    </blockquote>
-
-  <p>In section 19.3, change paragraph 2 from</p>
-
-    <blockquote>
-    The contents are the same as the Standard C library header
-    &lt;errno.h&gt;.
-    </blockquote>
-
-  <p>to</p>
-
-    <blockquote>
-    The contents are the same as the Standard C library header 
-    &lt;errno.h&gt;, except that errno shall be defined as a macro.
-    </blockquote>
-<p><b>Rationale:</b></p>
-<p>C++ must not leave it up to the implementation to decide whether
-or not a name is a macro; it must explicitly specify exactly which
-names are required to be macros.</p>
-<hr>
-<a name="311"><h3>311.&nbsp;Incorrect wording in basic_ostream class synopsis</h3></a><p>
-<b>Section:</b>&nbsp;27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
-
-<p>In 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
-
-<pre>
-  // partial specializationss
-  template&lt;class traits&gt;
-    basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
-                                            const char * );
-</pre>
-
-<p>Problems:</p>
-<ul>
-<li>Too many 's's at the end of &quot;specializationss&quot; </li>
-<li>This is an overload, not a partial specialization</li>
-</ul>
-
-<p><b>Proposed resolution:</b></p>
-<p>In the synopsis in 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the 
-<i>// partial specializationss</i> comment.  Also remove the same 
-comment (correctly spelled, but still incorrect) from the synopsis in 
-27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
-</p>
-
-<p><i>[
-Pre-Redmond: added 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
-comment in c++std-lib-8939.
-]</i></p>
-
-<hr>
-<a name="315"><h3>315.&nbsp;Bad &quot;range&quot; in list::unique complexity</h3></a><p>
-<b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
-<p>
-23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
-list::unique as: &quot;If the range (last - first) is not empty, exactly
-(last - first) -1 applications of the corresponding predicate,
-otherwise no applications of the predicate)&quot;.
-</p>
-
-<p>
-&quot;(last - first)&quot; is not a range.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the &quot;range&quot; from (last - first) to [first, last).
-</p>
-<hr>
-<a name="316"><h3>316.&nbsp;Vague text in Table 69</h3></a><p>
-<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
-<p>Table 69 says this about a_uniq.insert(t):</p>
-
-<blockquote>
-inserts t if and only if there is no element in the container with key
-equivalent to the key of t. The bool component of the returned pair 
-indicates whether the insertion takes place and the iterator component of the
-pair points to the element with key equivalent to the key of t.
-</blockquote>
-
-<p>The description should be more specific about exactly how the bool component
-indicates whether the insertion takes place.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in question to</p>
-
-<blockquote>
-...The bool component of the returned pair is true if and only if the insertion
-takes place...
-</blockquote>
-<hr>
-<a name="317"><h3>317.&nbsp;Instantiation vs. specialization of facets</h3></a><p>
-<b>Section:</b>&nbsp;22 <a href="lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
-<p>
-The localization section of the standard refers to specializations of
-the facet templates as instantiations even though the required facets
-are typically specialized rather than explicitly (or implicitly)
-instantiated. In the case of ctype&lt;char&gt; and
-ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
-actually required to be specialized. The terminology should be
-corrected to make it clear that the standard doesn't mandate explicit
-instantiation (the term specialization encompasses both explicit
-instantiations and specializations).
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In the following paragraphs, replace all occurrences of the word
-instantiation or instantiations with specialization or specializations,
-respectively:
-</p>
-
-<blockquote>
-22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
-22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
-22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
-Footnote 242.
-</blockquote>
-
-<p>And change the text in 22.1.1.1.1, p4 from</p>
-
-<blockquote>
-    An implementation is required to provide those instantiations
-    for facet templates identified as members of a category, and
-    for those shown in Table 52:
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
-    An implementation is required to provide those specializations...
-</blockquote>
-
-<p><i>[Nathan will review these changes, and will look for places where
-explicit specialization is necessary.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>This is a simple matter of outdated language.  The language to
-describe templates was clarified during the standardization process,
-but the wording in clause 22 was never updated to reflect that
-change.</p>
-<hr>
-<a name="318"><h3>318.&nbsp;Misleading comment in definition of numpunct_byname</h3></a><p>
-<b>Section:</b>&nbsp;22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 May 2001</p>
-<p>The definition of the numpunct_byname template contains the following
-comment:</p>
-
-<pre>
-    namespace std {
-        template &lt;class charT&gt;
-        class numpunct_byname : public numpunct&lt;charT&gt; {
-    // this class is specialized for char and wchar_t.
-        ...
-</pre>
-
-<p>There is no documentation of the specializations and it seems
-conceivable that an implementation will not explicitly specialize the
-template at all, but simply provide the primary template.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the comment from the text in 22.2.3.2 and from the proposed
-resolution of library issue <a href="lwg-defects.html#228">228</a>.</p>
-<hr>
-<a name="319"><h3>319.&nbsp;Storage allocation wording confuses &quot;Required behavior&quot;, &quot;Requires&quot;</h3></a><p>
-<b>Section:</b>&nbsp;18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;15 May 2001</p>
-<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that &quot;Required
-behavior&quot; elements describe &quot;the semantics of a function definition
-provided by either the implementation or a C++ program.&quot;</p>
-
-<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that &quot;Requires&quot;
-elements describe &quot;the preconditions for calling the function.&quot;</p>
-
-<p>In the sections noted below, the current wording specifies
-&quot;Required Behavior&quot; for what are actually preconditions, and thus
-should be specified as &quot;Requires&quot;.</p>
-
-<p><b>Proposed resolution:</b></p>
-
-<p>In 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
-<blockquote>
-  <p>Required behavior: accept a value of ptr that is null or that was
-  returned by an earlier call ...</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
-  <p>Requires: the value of ptr is null or the value returned by an
-  earlier call ...</p>
-</blockquote>
-
-<p>In 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
-<blockquote>
-  <p>Required behavior: accept a value of ptr that is null or that was
-  returned by an earlier call ...</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
-  <p>Requires: the value of ptr is null or the value returned by an
-  earlier call ...</p>
-</blockquote>
-
-<hr>
 <a name="320"><h3>320.&nbsp;list::assign overspecified</h3></a><p>
-<b>Section:</b>&nbsp;23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
+<b>Section:</b>&nbsp;23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
 <p>
 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
 the &quot;effects&quot; of a call to erase followed by a call to insert.
@@ -4351,11 +3416,15 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
 </blockquote>
 
 <p>In 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements), 
-add a new row:</p>
+add two new rows:</p>
 <pre>
       a.assign(i,j)     void      pre: i,j are not iterators into a.
-                                  Replaces elements in a with copies
-                                  of elements in [i, j).
+                                  Replaces elements in a with a copy
+                                  of [i, j).
+
+      a.assign(n,t)     void      pre: t is not a reference into a.
+                                  Replaces elements in a with n copies
+                                  of t.
 </pre>
 
 <p>Change 23.2.2.1/8 from:</p>
@@ -4380,58 +3449,14 @@ Also, the change in the sequence requirements is new.  Without that
 change, the proposed resolution would have required that assignment of
 a subrange would have to work.  That too would have been
 overspecification; it would effectively mandate that assignment use a
-temporary.
+temporary.  Howard provided wording.
 ]</i></p>
 
-<hr>
-<a name="321"><h3>321.&nbsp;Typo in num_get</h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Kevin Djang&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
-<p>
-Section 22.2.2.1.2 at p7 states that &quot;A length specifier is added to
-the conversion function, if needed, as indicated in Table 56.&quot;
-However, Table 56 uses the term &quot;length modifier&quot;, not &quot;length
-specifier&quot;.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 22.2.2.1.2 at p7, change the text &quot;A length specifier is added ...&quot;
-to be &quot;A length modifier is added ...&quot;
-</p>
-<p><b>Rationale:</b></p>
-<p>C uses the term &quot;length modifier&quot;.  We should be consistent.</p>
-<hr>
-<a name="322"><h3>322.&nbsp;iterator and const_iterator should have the same value type</h3></a><p>
-<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
-<p>
-It's widely assumed that, if X is a container,
-iterator_traits&lt;X::iterator&gt;::value_type and
-iterator_traits&lt;X::const_iterator&gt;::value_type should both be
-X::value_type.  However, this is nowhere stated.  The language in
-Table 65 is not precise about the iterators' value types (it predates
-iterator_traits), and could even be interpreted as saying that
-iterator_traits&lt;X::const_iterator&gt;::value_type should be &quot;const
-X::value_type&quot;.
-</p>
+<p><i>[Cura&ccedil;ao: Made editorial improvement in wording; changed
+&quot;Replaces elements in a with copies of elements in [i, j).&quot;
+with &quot;Replaces the elements of a with a copy of [i, j).&quot;
+Changes not deemed serious enough to requre rereview.]</i></p>
 
-<p>Related issue: <a href="lwg-closed.html#279">279</a>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In Table 65 (&quot;Container Requirements&quot;), change the return type for
-X::iterator to &quot;iterator type whose value type is T&quot;.  Change the
-return type for X::const_iterator to &quot;constant iterator type whose
-value type is T&quot;.</p>
-<p><b>Rationale:</b></p>
-<p>
-This belongs as a container requirement, rather than an iterator
-requirement, because the whole notion of iterator/const_iterator
-pairs is specific to containers' iterator.
-</p>
-<p>
-It is existing practice that (for example) 
-iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
-is &quot;int&quot;, rather than &quot;const int&quot;.  This is consistent with
-the way that const pointers are handled: the standard already 
-requires that iterator_traits&lt;const int*&gt;::value_type is int.
-</p>
 <hr>
 <a name="323"><h3>323.&nbsp;abs() overloads in different headers</h3></a><p>
 <b>Section:</b>&nbsp;26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;4 June 2001</p>
@@ -4487,7 +3512,7 @@ defined in which headers. (See issue <a href="lwg-closed.html#343">343</a>)]</i>
 
 <hr>
 <a name="324"><h3>324.&nbsp;Do output iterators have value types?</h3></a><p>
-<b>Section:</b>&nbsp;24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
+<b>Section:</b>&nbsp;24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
 
 <p>Table 73 suggests that output iterators have value types.  It 
 requires the expression &quot;*a = t&quot;.  Additionally, although Table 73
@@ -4540,7 +3565,7 @@ output iterators' pointer and reference types?</p>
 <blockquote>
 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
 in a value of some class, enumeration, or built-in type <tt>T</tt>,
-called the value type of the itereator.</p>
+called the value type of the iterator.</p>
 </blockquote>
 
 <p>to</p>
@@ -4611,7 +3636,7 @@ and any language suggesting otherwise is simply a mistake.</p>
 decision.</p>
 <hr>
 <a name="325"><h3>325.&nbsp;Misleading text in moneypunct&lt;&gt;::do_grouping</h3></a><p>
-<b>Section:</b>&nbsp;22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
+<b>Section:</b>&nbsp;22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
 <p>The Returns clause in 22.2.6.3.2, p3 says about
 moneypunct&lt;charT&gt;::do_grouping()
 </p>
@@ -4663,47 +3688,8 @@ locale. It is just a reminder that the values are interpreted as small
 integers, not ASCII characters.
 </p>
 <hr>
-<a name="327"><h3>327.&nbsp;Typo in time_get facet in table 52</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Tiki Wan&nbsp; <b>Date:</b>&nbsp;06 Jul 2001</p>
-<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
-<tt>time_get_byname</tt> are listed incorrectly in table 52,
-required instantiations.  In both cases the second template
-parameter is given as OutputIterator.  It should instead be
-InputIterator, since these are input facets.</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In table 52, required instantiations, in 
-22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
-<pre>
-    time_get&lt;wchar_t, OutputIterator&gt;
-    time_get_byname&lt;wchar_t, OutputIterator&gt;
-</pre>
-<p>to</p>
-<pre>
-    time_get&lt;wchar_t, InputIterator&gt;
-    time_get_byname&lt;wchar_t, InputIterator&gt;
-</pre>
-
-<p><i>[Redmond: Very minor change in proposed resolution.  Original had
-a typo, wchart instead of wchar_t.]</i></p>
-
-<hr>
-<a name="328"><h3>328.&nbsp;Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3></a><p>
-<b>Section:</b>&nbsp;22.2.6.2.2 <a href="lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;07 Jul 2001</p>
-<p>The sprintf format string , &quot;%.01f&quot; (that's the digit one), in the
-description of the do_put() member functions of the money_put facet in
-22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
-for values of type long double, and second, the precision of 01
-doesn't seem to make sense. What was most likely intended was
-&quot;%.0Lf&quot;., that is a precision of zero followed by the L length
-modifier.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the format string to &quot;%.0Lf&quot;.</p>
-<p><b>Rationale:</b></p>
-<p>Fixes an obvious typo</p>
-<hr>
 <a name="329"><h3>329.&nbsp;vector capacity, reserve and reallocation</h3></a><p>
-<b>Section:</b>&nbsp;23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
+<b>Section:</b>&nbsp;23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
 <p>
 There is an apparent contradiction about which circumstances can cause
 a reallocation of a vector in Section 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
@@ -4784,45 +3770,8 @@ the argument to the first, the intent was for the second invocation to
 have no effect.  Wording implying that such cases have an effect on
 reallocation guarantees was inadvertant.</p>
 <hr>
-<a name="331"><h3>331.&nbsp;bad declaration of destructor for ios_base::failure</h3></a><p>
-<b>Section:</b>&nbsp;27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;23 Aug 2001</p>
-<p>
-With the change in 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state
-   &quot;An implementation may strengthen the exception-specification for a 
-    non-virtual function by removing listed exceptions.&quot;
-(issue <a href="lwg-defects.html#119">119</a>)
-and the following declaration of ~failure() in ios_base::failure
-</p>
-<pre>
-    namespace std {
-       class ios_base::failure : public exception {
-       public:
-           ...
-           virtual ~failure();
-           ...
-       };
-     }
-</pre>
-<p>the class failure cannot be implemented since in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty
-exception specification:</p>
-<pre>
-    namespace std {
-       class exception {
-       public:
-         ...
-         virtual ~exception() throw();
-         ...
-       };
-     }
-</pre>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the declaration of ~failure().</p>
-<p><b>Rationale:</b></p>
-<p>The proposed resolution is consistent with the way that destructors
-of other classes derived from <tt>exception</tt> are handled.</p>
-<hr>
 <a name="333"><h3>333.&nbsp;does endl imply synchronization with the device?</h3></a><p>
-<b>Section:</b>&nbsp;27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
+<b>Section:</b>&nbsp;27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
 <p>A footnote in 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
 <blockquote>
     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a 
@@ -4857,7 +3806,7 @@ because it appears to make promises about what <tt>flush</tt>
 does.</p>
 <hr>
 <a name="334"><h3>334.&nbsp;map::operator[] specification forces inefficient implementation</h3></a><p>
-<b>Section:</b>&nbsp;23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
+<b>Section:</b>&nbsp;23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
 <p>
 The current standard describes map::operator[] using a
 code example. That code example is however quite
@@ -4957,49 +3906,15 @@ clause 17 saying that we do not intend the semantics of sample code
 fragments to be interpreted as specifing exactly how many copies are
 made.  See issue <a href="lwg-active.html#98">98</a> for a similar problem.]</i></p>
 
-<hr>
-<a name="335"><h3>335.&nbsp;minor issue with char_traits, table 37</h3></a><p>
-<b>Section:</b>&nbsp;21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;06 Sep 2001</p>
-<p>
-Table 37, in 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
-as:
-</p>
-<pre>
-  X::assign(c,d)   assigns c = d.
-</pre>
-
-<p>And para 1 says:</p>
-
-<blockquote>
- [...] c and d denote values of type CharT [...]
-</blockquote>
-
+<p><b>Rationale:</b></p>
 <p>
-Naturally, if c and d are <i>values</i>, then the assignment is
-(effectively) meaningless. It's clearly intended that (in the case of
-assign, at least), 'c' is intended to be a reference type.
-</p>
-
-<p>I did a quick survey of the four implementations I happened to have
-lying around, and sure enough they all have signatures:</p>
-<pre>
-    assign( charT&amp;, const charT&amp; );
-</pre>
-
-<p>(or the equivalent). It's also described this way in Nico's book.
-(Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
-and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
+This is the second solution described above; as noted, it is
+consistent with existing practice.
 </p>
-<p><b>Proposed resolution:</b></p>
-<p>Add the following to 21.1.1 para 1:</p>
-<blockquote>
- r denotes an lvalue of CharT
-</blockquote>
 
-<p>and change the description of assign in the table to:</p>
-<pre>
-  X::assign(r,d)   assigns r = d
-</pre>
+<p>Note that we now need to specify the complexity explicitly, because
+we are no longer defining <tt>operator[]</tt> in terms of
+<tt>insert</tt>.</p>
 <hr>
 <a name="336"><h3>336.&nbsp;Clause 17 lack of references to deprecated headers</h3></a><p>
 <b>Section:</b>&nbsp;17 <a href="lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;05 Sep 2001</p>
@@ -5017,22 +3932,13 @@ library (though a deprecated one).</p>
 to table 11.  A review is needed to determine whether there are any
 other places in clause 17 where clause D material should be referred
 to. Beman will review clause 17.]</i></p>
-<hr>
-<a name="337"><h3>337.&nbsp;replace_copy_if's template parameter should be InputIterator</h3></a><p>
-<b>Section:</b>&nbsp;25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;07 Sep 2001</p>
-<p>From c++std-edit-876:</p>
 
-<p>
-In section 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
-parameter of template replace_copy_if should be &quot;InputIterator&quot;
-instead of &quot;Iterator&quot;.  According to 17.3.2.1 <a href="lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
-parameter name conveys real normative meaning.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
+<p><i>[Cura&ccedil;ao: Beman emailed wording to Matt, but not in time for the
+pre-meeting mailing.]</i></p>
+
 <hr>
 <a name="338"><h3>338.&nbsp; is whitespace allowed between `-' and a digit?</h3></a><p>
-<b>Section:</b>&nbsp;22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
+<b>Section:</b>&nbsp;22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
 <p>
 From Stage 2 processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
 original text or the text corrected by the proposed resolution of
@@ -5094,7 +4000,7 @@ numeric processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.vir
 resolution removes all mention of &quot;whitespace&quot; from that format.</p>
 <hr>
 <a name="339"><h3>339.&nbsp;definition of bitmask type restricted to clause 27</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
+<b>Section:</b>&nbsp;22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
 <p>
 The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
 likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
@@ -5128,7 +4034,7 @@ following (note, in particluar, the cross-reference to 17.3.2.1.2 in
 namespace std {
     class ctype_base {
     public:
-        typedef T mask;
+        typedef <b><i>T</i></b> mask;
 
         // numeric values are for exposition only.
         static const mask space = 1 &lt;&lt; 0;
@@ -5149,10 +4055,13 @@ namespace std {
 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
 </blockquote>
 
+<p><i>[Cura&ccedil;ao: The LWG notes that T above should be bold-italics to be
+consistent with the rest of the standard.]</i></p>
+
 <hr>
 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
+<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
 <p>
 It's unclear whether 22.1.1.1.1, p3 says that
 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
@@ -5210,7 +4119,7 @@ OutputIterator must be supported.  Table 51 already contains a
 complete list of the ones we need.</p>
 <hr>
 <a name="341"><h3>341.&nbsp;Vector reallocation and swap</h3></a><p>
-<b>Section:</b>&nbsp;23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
+<b>Section:</b>&nbsp;23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
 an empty one:</p>
 <pre>
@@ -5272,7 +4181,6 @@ containers.]</i></p>
 swap should be constant time.  The clear intent is that it should just
 do pointer twiddling, and that it should exchange all properties of
 the two vectors, including their reallocation guarantees.
-ay be useful.
 </p>
 <hr>
 <a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p>
@@ -5349,63 +4257,8 @@ examined by the user to determine why something failed.</p>
 places where we have a problem, where the difference between
 <tt>fail()</tt> and <tt>!good()</tt> is important.]</i></p>
 <hr>
-<a name="345"><h3>345.&nbsp;type tm in &lt;cwchar&gt;</h3></a><p>
-<b>Section:</b>&nbsp;21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Clark Nelson&nbsp; <b>Date:</b>&nbsp;19 Oct 2001</p>
-<p>
-C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
-declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
-&lt;cwchar&gt;. Is this omission intentional or accidental?
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>In section 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add &quot;tm&quot; to table 48.</p>
-<hr>
-<a name="346"><h3>346.&nbsp;Some iterator member functions should be const</h3></a><p>
-<b>Section:</b>&nbsp;24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
-<p>Iterator member functions and operators that do not change the state
-of the iterator should be defined as const member functions or as
-functions that take iterators either by const reference or by
-value. The standard does not explicitly state which functions should
-be const.  Since this a fairly common mistake, the following changes
-are suggested to make this explicit.</p>
-
-<p>The tables almost indicate constness properly through naming: r
-for non-const and a,b for const iterators. The following changes
-make this more explicit and also fix a couple problems.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
-&quot;In the following sections, a and b denote values of X...&quot; to
-&quot;In the following sections, a and b denote values of type const X...&quot;.</p>
-
-<p>In Table 73, change</p>
-<pre>
-    a-&gt;m   U&amp;         ...
-</pre>
-
-<p>to</p>
-
-<pre>
-    a-&gt;m   const U&amp;   ...
-    r-&gt;m   U&amp;         ...
-</pre>
-
-<p>In Table 73 expression column, change</p>
-
-<pre>
-    *a = t
-</pre>
-
-<p>to</p>
-
-<pre>
-    *r = t
-</pre>
-
-<p><i>[Redmond: The container requirements should be reviewed to see if
-the same problem appears there.]</i></p>
-
-<hr>
 <a name="347"><h3>347.&nbsp;locale::category and bitmask requirements</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger, Nathan Myers&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
+<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger, Nathan Myers&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
 <p>
 In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
 are described as bitmask elements.  In fact, the bitmask requirements
@@ -5485,9 +4338,11 @@ of the other enumerated values; implementations may add extra categories.]
 </p>
 </blockquote>
 
+<p><i>[Cura&ccedil;ao: need input from locale experts.]</i></p>
+
 <hr>
 <a name="348"><h3>348.&nbsp;Minor issue with std::pair operator&lt;</h3></a><p>
-<b>Section:</b>&nbsp;20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
+<b>Section:</b>&nbsp;20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
 <p>
 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
 operator&lt; on any pair type which contains a pointer.
@@ -5504,9 +4359,18 @@ operator&lt; on any pair type which contains a pointer.
              (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp; 
              std::less&lt;T2&gt;()( x.second, y.second ) )
 </pre>
+
+<p><i>[Cura&ccedil;ao: LWG leaning toward NAD.&nbsp; In favor of the PR is
+that it removes a trap for users.&nbsp; Concerns: 1) will break some
+small amount of existing code (which define less and operator &lt;
+with different behavior), 2) don't have any indication of rationale
+for current design (and unwilling to change without knowing
+rationale), 3) consistency; pairs of ptrs would behave differenly from
+individual pointers.]</i></p>
+
 <hr>
 <a name="349"><h3>349.&nbsp;Minor typographical error in ostream_iterator</h3></a><p>
-<b>Section:</b>&nbsp;24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
+<b>Section:</b>&nbsp;24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
 <p>24.5.2 [lib.ostream.iterator] states:</p>
 <pre>
     [...]
@@ -5525,7 +4389,7 @@ In 24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterat
 </p>
 <hr>
 <a name="350"><h3>350.&nbsp;allocator&lt;&gt;::address</h3></a><p>
-<b>Section:</b>&nbsp;20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;25 Oct 2001</p>
+<b>Section:</b>&nbsp;20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;25 Oct 2001</p>
 <p>See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
 verbatim from -9007.</p>
 
@@ -5550,6 +4414,14 @@ no semantics at all for member address(), and allocator&lt;&gt;::address is
 defined in terms of unadorned operator &amp;.
 </p>
 
+<p><i>[Cura&ccedil;ao: The LWG believes both examples are ill-formed.&nbsp;
+The contained type is required to be CopyConstructible (20.1.3), and
+that includes the requirement that &amp;t return the usual types and
+values. Since the CopyConstructible requirements appear to have been
+written to deal with the concerns of this issue, the LWG feels it is
+NAD unless someone can come up with a well-formed example exhibiting a
+problem.]</i></p>
+
 <p><b>Proposed resolution:</b></p>
 <p>
 In 20.4.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
@@ -5581,6 +4453,9 @@ a.address(s) lines, respectively:
  operator&amp; may be overloaded.
 </blockquote> 
 
+<p><i>[Cura&ccedil;ao: If the issues isn't NAD, suggest changing &quot;if not
+overloaded&quot; to &quot;ignoring all overloads&quot;.]</i></p>
+
 <p><b>Rationale:</b></p>
 <p>The obvious implementations for std::allocator&lt;&gt;::address are</p>
 <pre>
@@ -5598,6 +4473,816 @@ but to define them formally in terms of reinterpret_cast&lt;&gt; seems
 to introduce semantic difficulties best avoided.  Using a.address()
 should not introduce unspecified or implementation-defined semantics
 into a user program.</p>
+<hr>
+<a name="352"><h3>352.&nbsp;missing fpos requirements</h3></a><p>
+<b>Section:</b>&nbsp;21.1.2 <a href="lib-strings.html#lib.char.traits.typedefs"> [lib.char.traits.typedefs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Dec 2001</p>
+<p>
+<i>(1)</i>
+There are no requirements on the <tt>stateT</tt> template parameter of
+<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
+the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
+and I think also DefaultConstructible (to implement the operations in
+Table 88).
+</p>
+<p>
+21.1.2, p3, however, only requires that
+<tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
+CopyConstructible types.
+</p>
+<p>
+<i>(2)</i>
+Additionally, the <tt>stateT</tt> template argument has no
+corresponding typedef in fpos which might make it difficult to use in
+generic code.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Modify 21.1.2, p4 from
+</p>
+<p>
+    Requires: <tt>state_type</tt> shall meet the requirements of
+              CopyConstructible types (20.1.3).
+</p>
+<p>
+    Requires: state_type shall meet the requirements of Assignable
+              (23.1, p4), CopyConstructible (20.1.3), and
+              DefaultConstructible  (20.1.4) types.
+</p>
+<p>
+Add to the definition of the fpos class template the following member:
+</p>
+<pre>
+    typedef stateT state_type;
+</pre>
+<p>
+and add to 27.4.3.1 a paragraph with the following text:
+</p>
+<pre>
+    typedef stateT state_type;
+</pre>
+<p>
+    Requires: <tt>state_type</tt> shall meet the requirements of
+              Assignable (23.1, p4), CopyConstructible (20.1.3), and
+              DefaultConstructible (20.1.4) types.
+</p>
+
+<p><i>[Cura&ccedil;ao: The LWG feels this is two issues, as indicated
+above. The first is a defect; more I/O experts need to review
+the PR. The second is questionable; who would use it? Unless
+motivation is provided, the second should be considered NAD.]</i></p>
+
+<hr>
+<a name="354"><h3>354.&nbsp;Associative container lower/upper bound requirements</h3></a><p>
+<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Aberg&nbsp; <b>Date:</b>&nbsp;17 Dec 2001</p>
+<p>
+Discussions in the thread &quot;Associative container lower/upper bound
+requirements&quot; on comp.std.c++ suggests that there is a defect in the
+C++ standard, Table 69 of section 23.1.2, &quot;Associative containers&quot;,
+[lib.associative.reqmts].  It currently says:</p>
+
+<blockquote>
+<p>
+a.find(k): returns an iterator pointing to an element with the key equivalent to
+k, or a.end() if such an element is not found.
+</p>
+
+<p>
+a.lower_bound(k): returns an iterator pointing to the first element with
+key not less than k.
+</p>
+
+<p>
+a.upper_bound(k): returns an iterator pointing to the first element with
+key greater than k.
+</p>
+</blockquote>
+
+<p>
+We have &quot;or a.end() if such an element is not found&quot; for
+<tt>find</tt>, but not for <tt>upper_bound</tt> or
+<tt>lower_bound</tt>.  As the text stands, one would be forced to
+insert a new element into the container and return an iterator to that
+in case the sought iterator does not exist, which does not seem to be
+the intention (and not possible with the &quot;const&quot; versions).
+</p>
+<p><b>Proposed resolution:</b></p>
+
+<p>Change Table 69 of section 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
+to:</p>
+
+<blockquote>
+<p>
+a.lower_bound(k): returns an iterator pointing to the first element with
+key not less than k, or a.end() if such an element is not found.
+</p>
+
+<p>
+a.upper_bound(k): returns an iterator pointing to the first element with
+key greater than k, or a.end() if such an element is not found.
+</p>
+</blockquote>
+
+<p><i>[Cura&ccedil;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="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
+
+<p>Table 68 &quot;Optional Sequence Operations&quot; in 23.1.1/12
+specifies operational semantics for &quot;a.back()&quot; as
+&quot;*--a.end()&quot;, which may be ill-formed <i>[because calling
+operator-- on a temporary (the return) of a built-in type is
+ill-formed]</i>, provided a.end() returns a simple pointer rvalue
+(this is almost always the case for std::vector::end(), for
+example). Thus, the specification is not only incorrect, it
+demonstrates a dangerous construct: &quot;--a.end()&quot; may
+successfully compile and run as intended, but after changing the type
+of the container or the mode of compilation it may produce
+compile-time error. </p>
+
+<p><b>Proposed resolution:</b></p>
+<p>Change the specification in table 68 &quot;Optional Sequence
+Operations&quot; in 23.1.1/12 for &quot;a.back()&quot; from</p>
+
+
+<blockquote>
+*--a.end()
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+  <p>*a.rbegin()</p>
+</blockquote>
+
+<p>and the specification for &quot;a.pop_back()&quot; from</p>
+
+<blockquote>
+a.erase(--a.end())
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+  <p>a.erase(rbegin())</p>
+</blockquote>
+
+<p><i>[Cura&ccedil;ao: LWG changed PR from &quot;{ X::iterator tmp =
+a.end(); return *--tmp; }&quot; to &quot;*a.rbegin()&quot;, and from
+&quot;{ X::iterator tmp = a.end(); a.erase(--tmp); }&quot; to
+&quot;a.erase(rbegin())&quot;.]</i></p>
+
+<p><i>[There is a second possible defect; table 68 &quot;Optional
+Sequence Operations&quot; in the &quot;Operational Semantics&quot;
+column uses operations present only in the &quot;Reversible
+Container&quot; requirements, yet there is no stated dependency
+between these separate requirements tables. Ask in Santa Cruz if the
+LWG would like a new issue opened.]</i></p>
+
+<hr>
+<a name="356"><h3>356.&nbsp;Meaning of ctype_base::mask enumerators</h3></a><p>
+<b>Section:</b>&nbsp;22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
+
+<p>What should the following program print?</p>
+
+<pre>
+  #include &lt;locale&gt;
+  #include &lt;iostream&gt;
+
+  class my_ctype : public std::ctype&lt;char&gt;
+  {
+    typedef std::ctype&lt;char&gt; base;
+  public:
+    my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
+    {
+      std::copy(base::classic_table(), base::classic_table() + base::table_size,
+                my_table);
+      my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
+    }
+  private:
+    mask my_table[base::table_size];
+  };
+
+  int main()
+  {
+    my_ctype ct;
+    std::cout &lt;&lt; &quot;isspace: &quot; &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; &quot;    &quot;
+              &lt;&lt; &quot;isalpha: &quot; &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
+  }
+</pre>
+
+<p>The goal is to create a facet where '_' is treated as whitespace.</p>
+
+<p>On gcc 3.0, this program prints &quot;isspace: 1 isalpha: 0&quot;.  On
+Microsoft C++ it prints &quot;isspace: 1 isalpha: 1&quot;.</p>
+
+<p>
+I believe that both implementations are legal, and the standard does not
+give enough guidance for users to be able to use std::ctype's
+protected interface portably.</p>
+
+<p>
+The above program assumes that ctype_base::mask enumerators like
+<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
+say that a character is both a space and a printing character is to or
+those two enumerators together.  This is suggested by the &quot;exposition
+only&quot; values in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in
+normative text.  An alternative interpretation is that the more
+specific categories subsume the less specific.  The above program
+gives the results it does on the Microsoft compiler because, on that
+compiler, <tt>print</tt> has all the bits set for each specific
+printing character class.
+</p>
+
+<p>From the point of view of std::ctype's public interface, there's no
+important difference between these two techniques.  From the point of
+view of the protected interface, there is.  If I'm defining a facet
+that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
+value that table()['a'] returns.  I need to know what combination of
+mask values I should use.  This isn't so very esoteric: it's exactly
+why std::ctype has a protected interface.  If we care about users
+being able to write their own ctype facets, we have to give them a
+portable way to do it.
+</p>
+
+<p>
+Related reflector messages:
+lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
+lib-9277, lib-9279.
+</p>
+
+<p>Issue <a href="lwg-active.html#339">339</a> is related, but not identical.  The
+proposed resolution if issue <a href="lwg-active.html#339">339</a> says that
+ctype_base::mask must be a bitmask type. It does not say that the
+ctype_base::mask elements are bitmask elements, so it doesn't
+directly affect this issue.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>Informally, we have three choices:</p> 
+<ol>
+<li>Require that the enumerators are disjoint (except for alnum and
+graph)</li>
+<li>Require that the enumerators are not disjoint, and specify which
+of them subsume which others.  (e.g. mandate that lower includes alpha
+and print)</li>
+<li>Explicitly leave this unspecified, which the result that the above
+program is not portable.</li>
+</ol>
+
+<p>Either of the first two options is just as good from the standpoint
+of portability.  Either one will require some implementations to
+change.</p>
+
+<hr>
+<a name="357"><h3>357.&nbsp;&lt;cmath&gt; float functions cannot return HUGE_VAL</h3></a><p>
+<b>Section:</b>&nbsp;26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;26 Feb 2002</p>
+<p>
+The float versions of the math functions have no meaningful value to return 
+for a range error. The long double versions have a value they can return, 
+but it isn't necessarily the most reasonable value.
+</p>
+
+<p>
+Section 26.5 [lib.c.math], paragraph 5, says that C++ &quot;adds float and long 
+double overloaded versions of these functions, with the same semantics,&quot; 
+referring to the math functions from the C90 standard.
+</p>
+
+<p>
+The C90 standard, in section 7.5.1, paragraph 3, says that functions return 
+&quot;the value of the macro HUGE_VAL&quot; when they encounter a range error. 
+Section 7.5, paragraph 2, defines HUGE_VAL as a macro that &quot;expands to a 
+positive double expression, not necessarily representable as a float.&quot;
+</p>
+
+<p>
+Therefore, the float versions of the math functions have no way to
+signal a range error. <i>[Cura&ccedil;ao: The LWG notes that this isn't
+strictly correct, since errno is set.]</i> The semantics require that they
+return HUGE_VAL, but they cannot because HUGE_VAL might not be
+representable as a float.
+</p>
+
+<p>
+The problem with long double functions is less severe because HUGE_VAL is 
+representable as a long double. On the other hand, it might not be a &quot;huge&quot; 
+long double value, and might fall well within the range of normal return 
+values for a long double function. Therefore, it does not make sense for a 
+long double function to return a double (HUGE_VAL) for a range error.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Cura&ccedil;ao: C99 was faced with a similar problem, which they fixed by
+adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
+
+<p>C++ must also fix, but it should be done in the context of the
+general C99 based changes to C++, not via DR. Thus the LWG in Cura&ccedil;ao
+felt the resolution should be NAD, FUTURE, but the issue is being held
+open for one more meeting to ensure LWG members not present during the
+discussion concur.</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="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</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
+integral part of the number, the first such occurrence should, IMO,
+terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
+and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
+interpreted in the fractional part of a number.)
+</p>
+
+<p>
+The easiest change I can think of that resolves this issue would be
+something like below.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the first sentence of 22.2.2.1.2, p9 from
+</p>
+
+<blockquote>
+    If discard is true then the position of the character is
+    remembered, but the character is otherwise ignored. If it is not
+    discarded, then a check is made to determine if c is allowed as
+    the next character of an input field of the conversion specifier
+    returned by stage 1. If so it is accumulated.
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+    If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
+    accumulated, then the position of the character is remembered, but
+    the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
+    already been accumulated, the character is discarded and Stage 2
+     terminates. ...
+</blockquote>
+
+<hr>
+<a name="359"><h3>359.&nbsp;num_put&lt;&gt;::do_put (..., bool) undocumented</h3></a><p>
+<b>Section:</b>&nbsp;22.2.2.2.1 <a href="lib-locales.html#lib.facet.num.put.members"> [lib.facet.num.put.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
+<p>22.2.2.2.1, p1:</p>
+
+    <pre>
+    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
+                   bool val) const;
+    ...
+
+    1   Returns: do_put (out, str, fill, val).
+    </pre>
+
+<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
+however, 22.2.2.2.2, p23:</p>
+
+<blockquote>
+<pre>
+iter_type put (iter_type out, ios_base&amp; str, char_type fill,
+               bool val) const;
+</pre>
+
+
+        Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
+             out = do_put(out, str, fill, (int)val)
+           Otherwise do
+<pre>
+             string_type s =
+                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
+                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
+</pre>
+           and then insert the characters of s into out. <i>out</i>.
+</blockquote>
+
+<p>
+This means that the bool overload of <tt>do_put()</tt> will never be called,
+which contradicts the first paragraph. Perhaps the declaration
+should read <tt>do_put()</tt>, and not <tt>put()</tt>?
+</p>
+
+<p>
+Note also that there is no <b>Returns</b> clause for this function, which
+should probably be corrected, just as should the second occurrence
+of <i>&quot;out.&quot;</i> in the text.
+</p>
+
+<p>
+I think the least invasive change to fix it would be something like
+the following:
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 22.2.2.2.2, p23, make the following changes
+</p>
+
+<blockquote>
+     Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
+     of the member function.
+</blockquote>
+
+<blockquote>
+    Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
+    avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
+    do_put (..., bool))</tt>
+    like so:
+</blockquote>
+
+<blockquote>
+    23   <b>Returns</b>: If <tt>(str.flags() &amp;
+         ios_base::boolalpha) == 0</tt> then
+         <tt>do_put (out, str, fill, (int)val)</tt>
+         Otherwise the function obtains a string <tt>s</tt> as if by
+<pre>
+             string_type s =
+                val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
+                    : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
+</pre>
+         and then inserts each character <tt>c</tt> of s into out via
+           <tt>*out++ = c</tt>
+         and returns <tt>out</tt>.
+</blockquote>
+
+<hr>
+<a name="360"><h3>360.&nbsp;locale mandates inefficient implementation</h3></a><p>
+<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
+<p>
+22.1.1, p7 (copied below) allows iostream formatters and extractors
+to make assumptions about the values returned from facet members.
+However, such assumptions are apparently not guaranteed to hold
+in other cases (e.g., when the facet members are being called directly
+rather than as a result of iostream calls, or between successive
+calls to the same iostream functions with no interevening calls to
+<tt>imbue()</tt>, or even when the facet member functions are called
+from other member functions of other facets). This restriction
+prevents locale from being implemented efficiently.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the first sentence in 22.1.1, p7 from</p>
+<blockquote>
+    In successive calls to a locale facet member function during
+    a call to an iostream inserter or extractor or a streambuf member
+    function, the returned result shall be identical. [Note: This
+    implies that such results may safely be reused without calling
+    the locale facet member function again, and that member functions
+    of iostream classes cannot safely call <tt>imbue()</tt>
+    themselves, except as specified elsewhere. --end note]
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+    In successive calls to a locale facet member function on a facet
+    object installed in the same locale, the returned result shall be
+    identical. ...
+</blockquote>
+
+<hr>
+<a name="361"><h3>361.&nbsp;num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3></a><p>
+<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
+<p>
+22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
+for integral types (issue 282 suggests that this should be done for
+all arithmetic types).
+</p>
+
+<p>
+22.2.2.1.2, p12 requires that grouping be checked for all extractors
+including that for <tt>void*</tt>.
+</p>
+
+<p>
+I don't think that's right. <tt>void*</tt> values should not be checked for
+grouping, should they? (Although if they should, then <tt>num_put</tt> needs
+to write them out, otherwise their extraction will fail.)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the first sentence of 22.2.2.2.2, p12 from
+</p>
+<blockquote>
+    Digit grouping is checked. That is, the positions of discarded
+    separators is examined for consistency with
+    use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
+    If they are not consistent then ios_base::failbit is assigned
+    to err.
+</blockquote>
+
+<p>to</p>
+<blockquote>
+    Except for conversions to void*, digit grouping is checked...
+</blockquote>
+
+<hr>
+<a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p>
+<b>Section:</b>&nbsp;20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</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="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
+the construction of an unsafe binding between incompatible pointer
+types. For example, given a function whose first parameter type is
+'pointer to T', it's possible without error to bind an argument of
+type 'pointer to U' when U does not derive from T:
+</p>
+<pre>
+   foo(T*, int);
+
+   struct T {};
+   struct U {};
+
+   U u;
+
+   int* p;
+   int* q;
+
+   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
+</pre>
+
+<p>
+The definition of bind1st() includes a functional-style conversion to
+map its argument to the expected argument type of the bound function
+(see below):
+</p>
+<pre>
+  typename Operation::first_argument_type(x)
+</pre>
+
+<p>
+A functional-style conversion (5.2.3 <a href="expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
+semantically equivalent to an explicit cast expression (5.4 <a href="expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
+as a reinterpret_cast, thus masking the error.
+</p>
+
+<p>The problem and proposed change also apply to 20.3.6.4 <a href="lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+The simplest and most localized change to prevent such errors is to
+require bind1st() use a static_cast expression rather than the
+functional-style conversion; that is, have bind1st() return:
+</p>
+<pre>
+   binder1st&lt;Operation&gt;( op,
+     static_cast&lt;typename Operation::first_argument_type&gt;(x)).
+</pre>
+
+<p>
+A more agressive solution is to change the semantics of
+functional-style conversions to not permit a reinterpret_cast. For
+contexts that require the semantics of reinterpret_cast, the language
+may want to require the use of an explicit cast expression such as
+'(T) x' or 'reinterpret_cast&lt;T&gt;(x)' and limit the behavior of
+the functional notation to match statically-checked and standard
+conversions (as defined by 5.2.9 and 4.10, etc.).  Although changing
+the semantics of functional-style conversions may seem drastic and
+does have language-wide ramifications, it has the benefit of better
+unifying the conversion rules for user defined types and built-in
+types, which can be especially important for generic template
+programming.
+</p>
+<hr>
+<a name="363"><h3>363.&nbsp;Missing exception specification in 27.4.2.1.1</h3></a><p>
+<b>Section:</b>&nbsp;27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;20 May 2002</p>
+<p>
+The destructor of ios_base::failure should have an empty throw
+specification, because the destructor of its base class, exception, is
+declared in this way.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the destructor to</p>
+<pre>
+  virtual ~failure() throw();
+</pre>
+<hr>
+<a name="364"><h3>364.&nbsp;Inconsistent wording in 27.5.2.4.2</h3></a><p>
+<b>Section:</b>&nbsp;27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
+<p>
+27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
+clause for seekoff.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Make this paragraph, the Effects clause for setbuf, consistent in wording
+with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
+to indicate the purpose of setbuf:
+</p>
+
+<p>Original text:</p>
+
+<blockquote>
+1 Effects: Performs an operation that is defined separately for each
+class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
+</blockquote>
+
+<p>Proposed text:</p>
+
+<blockquote>
+1 Effects: Influences stream buffering in a way that is defined separately
+for each class derived from basic_streambuf in this clause
+(27.7.1.3, 27.8.1.4).
+</blockquote>
+
+<hr>
+<a name="365"><h3>365.&nbsp;Lack of const-qualification in clause 27</h3></a><p>
+<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
+<p>
+None of the following member functions are declared const, but we
+believe each should be. See document N1360 for details and rationale.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 27.5.2 and 27.5.2.2.3</p>
+<p>Replace</p>
+<pre>
+  streamsize in_avail();
+</pre>
+<p>with</p>
+<pre>
+  streamsize in_avail() const;
+</pre>
+
+<p>In 27.5.2 and 27.5.2.4.3, and  27.8.1.1 and 27.8.1.4</p>
+<p>Replace</p>
+<pre>
+  virtual streamsize showmanyc();
+</pre>
+<p>with</p>
+<pre>
+  virtual streamsize showmanyc() const;
+</pre>
+
+<p>In 27.6.1.1 and 27.6.1.3</p>
+<p>Replace</p>
+<pre>
+  pos_type tellg();
+</pre>
+<p>with</p>
+<pre>
+  pos_type tellg() const;
+</pre>
+
+<p>This requires additional change, because paragraph 37 describes the
+return value in terms of calls to non-const member functions. Either of
+the two following solutions would allow tellg to be declared const.</p>
+
+<p>Option 1: Implementers may cast away const-ness, to allow calling the
+non-const rdbuf.</p>
+<p>In paragraph 37, replace:</p>
+<pre>
+  .... rdbuf()
+  -&gt;pubseekoff(0, cur, in).
+</pre>
+<p>by</p>
+<pre>
+  .... const_cast&lt;basic_istream&lt;charT, traits&gt;*&gt;(this)-&gt;rdbuf()
+  -&gt;pubseekoff(0, cur, in).
+</pre>
+
+<p>Option 2: Provide const member functions to do the job. The proposals in
+a later section (specifically, the modifications concerning rdbuf
+throughout the iostream library) meet most of this need; we would also
+need the following addition to basic_streambuf:</p>
+
+<blockquote>
+<pre>
+basic_streambuf&lt;charT,traits&gt;::pos_type
+basic_streambuf&lt;charT,traits&gt;::position(ios_base::openmode mode =
+                                        ios_base::in|ios_base::out)
+                                        const;
+</pre>
+<p>Effects: same as calling basic_streambuf::pubseekoff(0, ios base::cur, mode)</p>
+</blockquote>
+
+<p>In 27.6.2.1 and 27.6.2.4</p>
+<p>Replace</p>
+<pre>
+  pos_type tellp();
+</pre>
+<p>with</p>
+<pre>
+  pos_type tell() const;
+</pre>
+
+<p>This requires additional change; see the discussion for tellg() above.</p>
+
+<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
+<p>Replace</p>
+<pre>
+  bool is_open();
+</pre>
+<p>with</p>
+<pre>
+  bool is_open() const;
+</pre>
+<hr>
+<a name="366"><h3>366.&nbsp;Excessive const-qualification</h3></a><p>
+<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
+<p>
+The following member functions are declared const, yet return non-const
+pointers. We believe they are should be changed, because they allow code
+that may surprise the user. See document N1360 for details and
+rationale.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 27.4.4 and 27.4.4.2</p>
+<p>Replace</p>
+<pre>
+  basic_ostream&lt;charT,traits&gt;* tie() const;
+</pre>
+<p>with</p>
+<pre>
+  basic_ostream&lt;charT,traits&gt;* tie();
+  const basic_ostream&lt;charT,traits&gt;* tie() const;
+</pre>
+
+<p>and replace</p>
+<pre>
+  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
+</pre>
+<p>with</p>
+<pre>
+  basic_streambuf&lt;charT,traits&gt;* rdbuf();
+  const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
+</pre>
+
+<p>In 27.5.2 and 27.5.2.3.1</p>
+<p>Replace</p>
+<pre>
+  char_type* eback() const;
+</pre>
+<p>with</p>
+<pre>
+  char_type* eback();
+  const char_type* eback() const;
+</pre>
+
+<p>Replace</p>
+<pre>
+  char_type gptr() const;
+</pre>
+<p>with</p>
+<pre>
+  char_type* gptr();
+  const char_type* gptr() const;
+</pre>
+
+<p>Replace</p>
+<pre>
+  char_type* egptr() const;
+</pre>
+<p>with</p>
+<pre>
+  char_type* egptr();
+  const char_type* egptr() const;
+</pre>
+
+<p>In 27.5.2 and 27.5.2.3.2</p>
+<p>Replace</p>
+<pre>
+  char_type* pbase() const;
+</pre>
+<p>with</p>
+<pre>
+  char_type* pbase();
+  const char_type* pbase() const;
+</pre>
+
+<p>Replace</p>
+<pre>
+  char_type* pptr() const;
+</pre>
+<p>with</p>
+<pre>
+  char_type* pptr();
+  const char_type* pptr() const;
+</pre>
+
+<p>Replace</p>
+<pre>
+  char_type* epptr() const;
+</pre>
+<p>with</p>
+<pre>
+  char_type* epptr();
+  const char_type* epptr() const;
+</pre>
+
+<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
+<p>Replace</p>
+<pre>
+  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
+</pre>
+<p>with</p>
+<pre>
+  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
+  const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
+</pre>
+
+<p>In  27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
+<p>Replace</p>
+<pre>
+  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
+</pre>
+<p>with</p>
+<pre>
+  basic_filebuf&lt;charT,traits&gt;* rdbuf();
+  const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
+</pre>
 <p>----- End of document -----</p>
 </body>
 </html>
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html
index bd3af81..eea548b 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -5,11 +5,11 @@
 <table>
 <tr>
 <td align="left">Doc. no.</td>
-<td align="left">J16/01-0053 = WG21 N1338</td>
+<td align="left">J16/02-0028 = WG21 N1370</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">09 Nov 2001</td>
+<td align="left">10 May 2002</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -20,7 +20,7 @@
 <td align="left">Matt Austern &lt;austern@research.att.com&gt;</td>
 </tr>
 </table>
-<h1>C++ Standard Library Defect Report List (Revision 20)</h1>
+<h1>C++ Standard Library Defect Report List (Revision 22)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
     <ul>
@@ -42,6 +42,12 @@
   document.</p>
 <h2>Revision History</h2>
 <ul>
+<li>R22: 
+Post-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
+</li>
+<li>R21: 
+Pre-Cura&ccedil;ao mailing.  Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-active.html#361">361</a>.
+</li>
 <li>R20: 
 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues 
@@ -49,19 +55,19 @@ new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">3
 not discussed at the meeting.  
 
 All Ready issues were moved to DR status, with the exception of issues
-<a href="lwg-active.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.
+<a href="lwg-defects.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.
 
 Noteworthy issues discussed at Redmond include 
 <a href="lwg-active.html#120">120</a> <a href="lwg-active.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>, 
-<a href="lwg-active.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
+<a href="lwg-defects.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
 </li>
 <li>R19: 
 Pre-Redmond mailing.  Added new issues 
-<a href="lwg-active.html#323">323</a>-<a href="lwg-active.html#335">335</a>.
+<a href="lwg-active.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
 </li>
 <li>R18: 
 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-active.html#317">317</a>, and discussed
+Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
 new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
 
 Changed status of issues
@@ -80,7 +86,7 @@ Changed status of issues
 <a href="lwg-defects.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
 <a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
 <a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
-<a href="lwg-defects.html#281">281</a> <a href="lwg-active.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
+<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
 <a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
 <a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
 <a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
@@ -95,8 +101,8 @@ as NAD.
 </li>
 <li>R17: 
 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
-resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-active.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
-Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-active.html#311">311</a>.
+resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
+Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
 </li>
 <li>R16:  
 post-Toronto mailing; reflects actions taken in Toronto. Added new
@@ -142,7 +148,7 @@ of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
 post-Kona mailing: Updated to reflect LWG and full committee actions
 in Kona (99-0048/N1224). Note changed resolution of issues
 <a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
-to <a href="lwg-active.html#198">198</a>. Closed issues list split into &quot;defects&quot; and
+to <a href="lwg-defects.html#198">198</a>. Closed issues list split into &quot;defects&quot; and
 &quot;closed&quot; documents.  Changed the proposed resolution of issue
 <a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
 of issue <a href="lwg-defects.html#38">38</a>.
@@ -2229,6 +2235,119 @@ change the <tt>stateT</tt> argument type on both member
   <tt>max</tt> elements.</p>
 </blockquote>
 <hr>
+<a name="76"><h3>76.&nbsp;Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p>
+<b>Section:</b>&nbsp;22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Sep 1998</p>
+<p>This issue concerns the requirements on classes derived from
+<tt>codecvt</tt>, including user-defined classes. What are the
+restrictions on the conversion from external characters
+(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
+Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
+the I/O library make? </p>
+
+<p>The question is whether it's possible to convert from internal
+characters to external characters one internal character at a time,
+and whether, given a valid sequence of external characters, it's
+possible to pick off internal characters one at a time. Or, to put it
+differently: given a sequence of external characters and the
+corresponding sequence of internal characters, does a position in the
+internal sequence correspond to some position in the external
+sequence? </p>
+
+<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
+sequence of <i>M</i> external characters and that <tt>[ifirst,
+ilast)</tt> is the corresponding sequence of <i>N</i> internal
+characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
+applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
+ilast)</tt>. Now the question: does there necessarily exist a
+subsequence of external characters, <tt>[first, last_1)</tt>, such
+that the corresponding sequence of internal characters is the single
+character <tt>*ifirst</tt>?
+</p>
+
+<p>(What a &quot;no&quot; answer would mean is that
+<tt>my_encoding</tt> translates sequences only as blocks. There's a
+sequence of <i>M</i> external characters that maps to a sequence of
+<i>N</i> internal characters, but that external sequence has no
+subsequence that maps to <i>N-1</i> internal characters.) </p>
+
+<p>Some of the wording in the standard, such as the description of
+<tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
+paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
+possible to pick off internal characters one at a time from a sequence
+of external characters. However, this is never explicitly stated one
+way or the other. </p>
+
+<p>This issue seems (and is) quite technical, but it is important if
+we expect users to provide their own encoding facets. This is an area
+where the standard library calls user-supplied code, so a well-defined
+set of requirements for the user-supplied code is crucial. Users must
+be aware of the assumptions that the library makes. This issue affects
+positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
+and several of <tt>codecvt</tt>'s member functions. </p>
+<p><b>Proposed resolution:</b></p>
+<p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
+
+<blockquote>
+<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
+(27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
+<pre>
+    do_out(state, from, from_end, from_next, to, to_lim, to_next)
+</pre>
+would return <tt>ok</tt>, where <tt>from != from_end</tt>, then 
+<pre>
+    do_out(state, from, from + 1, from_next, to, to_end, to_next)
+</pre>
+must also return <tt>ok</tt>, and that if
+<pre>
+    do_in(state, from, from_end, from_next, to, to_lim, to_next)
+</pre>
+would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
+<pre>
+    do_in(state, from, from_end, from_next, to, to + 1, to_next)
+</pre>
+<p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
+means that <tt>basic_filebuf</tt> assumes that the mapping from
+internal to external characters is 1 to N: a <tt>codecvt</tt> that is
+used by <tt>basic_filebuf</tt> must be able to translate characters
+one internal character at a time.  <i>--End Footnote</i>]</p>
+</blockquote>
+
+<p><i>[Redmond: Minor change in proposed resolution.  Original
+proposed resolution talked about &quot;success&quot;, with a parenthetical
+comment that success meant returning <tt>ok</tt>.  New wording
+removes all talk about &quot;success&quot;, and just talks about the
+return value.]</i></p>
+
+<p><b>Rationale:</b></p>
+
+  <p>The proposed resoluion says that conversions can be performed one
+  internal character at a time.  This rules out some encodings that
+  would otherwise be legal.  The alternative answer would mean there
+  would be some internal positions that do not correspond to any
+  external file position.</p>
+  <p>
+  An example of an encoding that this rules out is one where the
+  <tt>internT</tt> and <tt>externT</tt> are of the same type, and
+  where the internal sequence <tt>c1 c2</tt> corresponds to the
+  external sequence <tt>c2 c1</tt>.
+  </p>
+  <p>It was generally agreed that <tt>basic_filebuf</tt> relies
+  on this property: it was designed under the assumption that
+  the external-to-internal mapping is N-to-1, and it is not clear
+  that <tt>basic_filebuf</tt> is implementable without that 
+  restriction.
+  </p>
+  <p>
+  The proposed resolution is expressed as a restriction on
+  <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
+  than a blanket restriction on all <tt>codecvt</tt> facets,
+  because <tt>basic_filebuf</tt> is the only other part of the 
+  library that uses <tt>codecvt</tt>.  If a user wants to define
+  a <tt>codecvt</tt> facet that implements a more general N-to-M
+  mapping, there is no reason to prohibit it, so long as the user
+  does not expect <tt>basic_filebuf</tt> to be able to use it.
+  </p>
+<hr>
 <a name="78"><h3>78.&nbsp;Typo: event_call_back</h3></a><p>
 <b>Section:</b>&nbsp;27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>typo: event_call_back should be event_callback &nbsp; </p>
@@ -3210,7 +3329,7 @@ with:</p>
 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
 say:<br>
 <br>
-&#x97; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt>
+&#151; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt>
 </p>
 
 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
@@ -3220,11 +3339,11 @@ proposed resolution.]</i></p>
 <p><b>Proposed resolution:</b></p>
 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
 <br>
-&#x97; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
+&#151; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
 <br>
 </tt>to:<br>
 <tt><br>
-</tt>&#x97; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt>
+</tt>&#151; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt>
 </p>
 <hr>
 <a name="142"><h3>142.&nbsp;lexicographical_compare complexity wrong</h3></a><p>
@@ -3989,10 +4108,10 @@ proposed resolution passed their test suites.</p>
 omit the <tt> std::</tt> namespace qualification.</p> <p>For
 example, 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
 <blockquote>
-<pre>&#x97; operator new(size_t)
-&#x97; operator new(size_t, const std::nothrow_t&amp;)
-&#x97; operator new[](size_t)
-&#x97; operator new[](size_t, const std::nothrow_t&amp;)</pre>
+<pre>&#151; operator new(size_t)
+&#151; operator new(size_t, const std::nothrow_t&amp;)
+&#151; operator new[](size_t)
+&#151; operator new[](size_t, const std::nothrow_t&amp;)</pre>
 </blockquote>
 <p><b>Proposed resolution:</b></p>
 <p>   In 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
@@ -4522,6 +4641,132 @@ returns <tt>traits::eof()</tt>, the function calls
 </p>
 </blockquote>
 <hr>
+<a name="198"><h3>198.&nbsp;Validity of pointers and references unspecified after iterator destruction</h3></a><p>
+<b>Section:</b>&nbsp;24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Nov 1999</p>
+<p>
+Is a pointer or reference obtained from an iterator still valid after
+destruction of the iterator?
+</p>
+<p>
+Is a pointer or reference obtained from an iterator still valid after the value
+of the iterator changes?
+</p>
+<blockquote>
+<pre>
+#include &lt;iostream&gt;
+#include &lt;vector&gt;
+#include &lt;iterator&gt;
+
+int main()
+{
+    typedef std::vector&lt;int&gt; vec_t;
+    vec_t v;
+    v.push_back( 1 );
+
+    // Is a pointer or reference obtained from an iterator still
+    // valid after destruction of the iterator?
+    int * p = &amp;*v.begin();
+    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
+
+    // Is a pointer or reference obtained from an iterator still
+    // valid after the value of the iterator changes?
+    vec_t::iterator iter( v.begin() );
+    p = &amp;*iter++;
+    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
+
+    return 0;
+}
+</pre>
+</blockquote>
+
+<p>The standard doesn't appear to directly address these
+questions. The standard needs to be clarified. At least two real-world
+cases have been reported where library implementors wasted
+considerable effort because of the lack of clarity in the
+standard. The question is important because requiring pointers and
+references to remain valid has the effect for practical purposes of
+prohibiting iterators from pointing to cached rather than actual
+elements of containers.</p>
+
+<p>The standard itself assumes that pointers and references obtained
+from an iterator are still valid after iterator destruction or
+change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
+effects:</p>
+
+<blockquote>
+  <pre>Iterator tmp = current;
+return *--tmp;</pre>
+</blockquote>
+<p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4 <a href="lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
+<blockquote>
+  <pre>return &amp;(operator*());</pre>
+</blockquote>
+
+<p>Because the standard itself assumes pointers and references remain
+valid after iterator destruction or change, the standard should say so
+explicitly. This will also reduce the chance of user code breaking
+unexpectedly when porting to a different standard library
+implementation.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add a new paragraph to 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
+<blockquote>
+Destruction of an iterator may invalidate pointers and references
+previously obtained from that iterator.
+</blockquote>
+
+<p>Replace paragraph 1 of 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
+
+<blockquote>
+<p><b>Effects:</b></p>
+<pre>
+  this-&gt;tmp = current;
+  --this-&gt;tmp;
+  return *this-&gt;tmp;
+</pre>
+
+<p>
+[<i>Note:</i> This operation must use an auxiliary member variable,
+rather than a temporary variable, to avoid returning a reference that
+persists beyond the lifetime of its associated iterator.  (See
+24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.)  The name of this member variable is shown for
+exposition only.  <i>--end note</i>]
+</p>
+</blockquote>
+
+<p><i>[Post-Tokyo: The issue has been reformulated purely
+in terms of iterators.]</i></p>
+
+<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
+assumption by reverse_iterator. The issue and proposed resolution was
+reformulated yet again to reflect this reality.]</i></p>
+
+<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
+assumes its underlying iterator has persistent pointers and
+references.  Andy Koenig pointed out that it is possible to rewrite
+reverse_iterator so that it no longer makes such an assupmption.
+However, this issue is related to issue <a href="lwg-active.html#299">299</a>.  If we
+decide it is intentional that <tt>p[n]</tt> may return by value
+instead of reference when <tt>p</tt> is a Random Access Iterator,
+other changes in reverse_iterator will be necessary.]</i></p>
+<p><b>Rationale:</b></p>
+<p>This issue has been discussed extensively.  Note that it is
+<i>not</i> an issue about the behavior of predefined iterators.  It is
+asking whether or not user-defined iterators are permitted to have
+transient pointers and references.  Several people presented examples
+of useful user-defined iterators that have such a property; examples
+include a B-tree iterator, and an &quot;iota iterator&quot; that doesn't point
+to memory.  Library implementors already seem to be able to cope with
+such iterators: they take pains to avoid forming references to memory
+that gets iterated past.  The only place where this is a problem is
+<tt>reverse_iterator</tt>, so this issue changes
+<tt>reverse_iterator</tt> to make it work.</p>
+
+<p>This resolution does not weaken any guarantees provided by
+predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
+Clause 23 should be reviewed to make sure that guarantees for
+predefined iterators are as strong as users expect.</p>
+
+<hr>
 <a name="199"><h3>199.&nbsp;What does <tt>allocate(0)</tt> return?</h3></a><p>
 <b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
 <p>
@@ -5218,6 +5463,89 @@ defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
 we fixed it, it would say just the same thing as text that's already
 in the standard.</p>
 <hr>
+<a name="239"><h3>239.&nbsp;Complexity of unique() and/or unique_copy incorrect</h3></a><p>
+<b>Section:</b>&nbsp;25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
+<p>The complexity of unique and unique_copy are inconsistent with each
+other and inconsistent with the implementations.&nbsp; The standard
+specifies:</p>
+
+<p>for unique():</p>
+
+<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
+(last - first) - 1 applications of the corresponding predicate, otherwise
+no applications of the predicate.</blockquote>
+
+<p>for unique_copy():</p>
+
+<blockquote>-7- Complexity: Exactly last - first applications of the corresponding
+predicate.</blockquote>
+
+<p>
+The implementations do it the other way round: unique() applies the
+predicate last-first times and unique_copy() applies it last-first-1
+times.</p>
+
+<p>As both algorithms use the predicate for pair-wise comparison of
+sequence elements I don't see a justification for unique_copy()
+applying the predicate last-first times, especially since it is not
+specified to which pair in the sequence the predicate is applied
+twice.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change both complexity sections in 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
+
+<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
+applications of the corresponding predicate.</blockquote>
+
+<hr>
+<a name="240"><h3>240.&nbsp;Complexity of adjacent_find() is meaningless</h3></a><p>
+<b>Section:</b>&nbsp;25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
+<p>The complexity section of adjacent_find is defective:</p>
+
+<blockquote>
+<pre>
+template &lt;class ForwardIterator&gt;
+ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
+                              BinaryPredicate pred);
+</pre>
+
+<p>-1- Returns: The first iterator i such that both i and i + 1 are in
+the range [first, last) for which the following corresponding
+conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
+last if no such iterator is found.</p>
+
+<p>-2- Complexity: Exactly find(first, last, value) - first applications
+of the corresponding predicate.
+</p>
+</blockquote>
+
+<p>In the Complexity section, it is not defined what &quot;value&quot;
+is supposed to mean. My best guess is that &quot;value&quot; means an
+object for which one of the conditions pred(*i,value) or
+pred(value,*i) is true, where i is the iterator defined in the Returns
+section. However, the value type of the input sequence need not be
+equality-comparable and for this reason the term find(first, last,
+value) - first is meaningless.</p>
+
+<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
+find_if(first, last, bind1st(pred,*i)) - first might come closer to
+the intended specification.  Binders can only be applied to function
+objects that have the function call operator declared const, which is
+not required of predicates because they can have non-const data
+members. For this reason, a specification using a binder could only be
+an &quot;as-if&quot; specification.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the complexity section in 25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
+<blockquote>
+For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
+(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
+corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
+return value.
+</blockquote>
+
+<p><i>[Copenhagen: the original resolution specified an upper
+bound.  The LWG preferred an exact count.]</i></p>
+
+<hr>
 <a name="242"><h3>242.&nbsp;Side effects of function objects</h3></a><p>
 <b>Section:</b>&nbsp;25.2.3 <a href="lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
 <p>The algorithms transform(), accumulate(), inner_product(),
@@ -5894,6 +6222,259 @@ are missing.</p>
         locale(const locale&amp; other) throw();
 </pre>
 <hr>
+<a name="270"><h3>270.&nbsp;Binary search requirements overly strict</h3></a><p>
+<b>Section:</b>&nbsp;25.3.3 <a href="lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Oct 2000</p>
+<p>
+Each of the four binary search algorithms (lower_bound, upper_bound,
+equal_range, binary_search) has a form that allows the user to pass a
+comparison function object.  According to 25.3, paragraph 2, that
+comparison function object has to be a strict weak ordering.
+</p>
+
+<p>
+This requirement is slightly too strict.  Suppose we are searching
+through a sequence containing objects of type X, where X is some
+large record with an integer key.  We might reasonably want to look
+up a record by key, in which case we would want to write something
+like this:
+</p>
+<pre>
+    struct key_comp {
+      bool operator()(const X&amp; x, int n) const {
+        return x.key() &lt; n;
+      }
+    }
+
+    std::lower_bound(first, last, 47, key_comp());
+</pre>
+
+<p>
+key_comp is not a strict weak ordering, but there is no reason to
+prohibit its use in lower_bound.
+</p>
+
+<p>
+There's no difficulty in implementing lower_bound so that it allows
+the use of something like key_comp.  (It will probably work unless an
+implementor takes special pains to forbid it.)  What's difficult is
+formulating language in the standard to specify what kind of
+comparison function is acceptable.  We need a notion that's slightly
+more general than that of a strict weak ordering, one that can encompass
+a comparison function that involves different types.  Expressing that
+notion may be complicated.
+</p>
+
+<p><i>Additional questions raised at the Toronto meeting:</i></p>
+<ul>
+<li> Do we really want to specify what ordering the implementor must
+     use when calling the function object?  The standard gives 
+     specific expressions when describing these algorithms, but it also
+     says that other expressions (with different argument order) are
+     equivalent.</li>
+<li> If we are specifying ordering, note that the standard uses both
+     orderings when describing <tt>equal_range</tt>.</li>
+<li> Are we talking about requiring these algorithms to work properly
+     when passed a binary function object whose two argument types
+     are not the same, or are we talking about requirements when
+     they are passed a binary function object with several overloaded
+     versions of <tt>operator()</tt>?</li>
+<li> The definition of a strict weak ordering does not appear to give
+     any guidance on issues of overloading; it only discusses expressions,
+     and all of the values in these expressions are of the same type.
+     Some clarification would seem to be in order.</li>
+</ul>
+
+<p><i>Additional discussion from Copenhagen:</i></p>
+<ul>
+<li>It was generally agreed that there is a real defect here: if
+the predicate is merely required to be a Strict Weak Ordering, then
+it's possible to pass in a function object with an overloaded
+operator(), where the version that's actually called does something
+completely inappropriate.  (Such as returning a random value.)</li>
+
+<li>An alternative formulation was presented in a paper distributed by
+David Abrahams at the meeting, &quot;Binary Search with Heterogeneous
+Comparison&quot;, J16-01/0027 = WG21 N1313: Instead of viewing the
+predicate as a Strict Weak Ordering acting on a sorted sequence, view
+the predicate/value pair as something that partitions a sequence.
+This is almost equivalent to saying that we should view binary search
+as if we are given a unary predicate and a sequence, such that f(*p)
+is true for all p below a specific point and false for all p above it.
+The proposed resolution is based on that alternative formulation.</li>
+</ul>
+<p><b>Proposed resolution:</b></p>
+
+<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
+
+<blockquote>
+  3 For all algorithms that take Compare, there is a version that uses
+  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
+  *j != false. For the algorithms to work correctly, comp has to
+  induce a strict weak ordering on the values.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+  3 For all algorithms that take Compare, there is a version that uses
+  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
+  &lt; *j != false. For algorithms other than those described in
+  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
+  a strict weak ordering on the values.
+</blockquote>
+
+<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
+
+<blockquote>
+  -6- A sequence [start, finish) is partitioned with respect to an
+  expression f(e) if there exists an integer n such that
+  for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
+  and only if i &lt; n.
+</blockquote>
+
+<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
+
+<blockquote>
+  -1- All of the algorithms in this section are versions of binary
+   search and assume that the sequence being searched is in order
+   according to the implied or explicit comparison function. They work
+   on non-random access iterators minimizing the number of
+   comparisons, which will be logarithmic for all types of
+   iterators. They are especially appropriate for random access
+   iterators, because these algorithms do a logarithmic number of
+   steps through the data structure. For non-random access iterators
+   they execute a linear number of steps.
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+   -1- All of the algorithms in this section are versions of binary
+    search and assume that the sequence being searched is partitioned
+    with respect to an expression formed by binding the search key to
+    an argument of the implied or explicit comparison function. They
+    work on non-random access iterators minimizing the number of
+    comparisons, which will be logarithmic for all types of
+    iterators. They are especially appropriate for random access
+    iterators, because these algorithms do a logarithmic number of
+    steps through the data structure. For non-random access iterators
+    they execute a linear number of steps.
+</blockquote>
+
+<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
+
+<blockquote>
+   -1- Requires: Type T is LessThanComparable
+    (lib.lessthancomparable). 
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expression e &lt; value or comp(e, value)
+</blockquote>
+
+
+<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
+
+<blockquote>
+   -2- Effects: Finds the first position into which value can be
+    inserted without violating the ordering. 
+</blockquote>
+
+<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
+
+<blockquote>
+  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expression !(value &lt; e) or !comp(value, e)
+</blockquote>
+
+<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
+
+<blockquote>
+   -2- Effects: Finds the furthermost position into which value can be
+    inserted without violating the ordering.
+</blockquote>
+
+<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
+
+<blockquote>
+   -1- Requires: Type T is LessThanComparable
+    (lib.lessthancomparable).
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expressions e &lt; value and !(value &lt; e) or
+   comp(e, value) and !comp(value, e).  Also, for all elements e of
+   [first, last), e &lt; value implies !(value &lt; e) or comp(e,
+   value) implies !comp(value, e)
+</blockquote>
+
+<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
+
+<blockquote>
+   -2- Effects: Finds the largest subrange [i, j) such that the value
+    can be inserted at any iterator k in it without violating the
+    ordering. k satisfies the corresponding conditions: !(*k &lt; value)
+    &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
+    false.
+</blockquote>
+
+<p>to:</p>
+
+<pre>
+   -2- Returns: 
+         make_pair(lower_bound(first, last, value),
+                   upper_bound(first, last, value))
+       or
+         make_pair(lower_bound(first, last, value, comp),
+                   upper_bound(first, last, value, comp))
+</pre>
+
+<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
+
+<blockquote>
+   -1- Requires: Type T is LessThanComparable
+    (lib.lessthancomparable).
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+   -1- Requires: The elements e of [first, last) are partitioned with
+   respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
+   value) and !comp(value, e). Also, for all elements e of [first,
+   last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
+   !comp(value, e)
+</blockquote>
+
+<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
+
+<p><i>[Redmond: Minor changes in wording.  (Removed &quot;non-negative&quot;, and
+changed the &quot;other than those described in&quot; wording.) Also, the LWG
+decided to accept the &quot;optional&quot; part.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>The proposed resolution reinterprets binary search. Instead of
+thinking about searching for a value in a sorted range, we view that
+as an important special case of a more general algorithm: searching
+for the partition point in a partitioned range.</p>
+
+<p>We also add a guarantee that the old wording did not: we ensure
+that the upper bound is no earlier than the lower bound, that
+the pair returned by equal_range is a valid range, and that the first
+part of that pair is the lower bound.</p>
+<hr>
 <a name="271"><h3>271.&nbsp;basic_iostream missing typedefs</h3></a><p>
 <b>Section:</b>&nbsp;27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
 <p>
@@ -5943,6 +6524,62 @@ class (14.6.2 [temp.dep]) and thus not visible.</p>
 <p>Qualify the names with the name of the class of which they are
 members, i.e., ios_base.</p>
 <hr>
+<a name="274"><h3>274.&nbsp;a missing/impossible allocator requirement</h3></a><p>
+<b>Section:</b>&nbsp;20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
+<p>
+I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
+any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
+be overloaded on reference and const_reference, which is ill-formed for
+all T = const U. In other words, this won't work:
+</p>
+
+<p>
+template class std::allocator&lt;const int&gt;;
+</p>
+
+<p>
+The obvious solution is to disallow specializations of allocators on
+const types. However, while containers' elements are required to be
+assignable (which rules out specializations on const T's), I think that
+allocators might perhaps be potentially useful for const values in other
+contexts. So if allocators are to allow const types a partial
+specialization of std::allocator&lt;const T&gt; would probably have to be
+provided.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
+
+    <blockquote>
+    any type
+    </blockquote>
+
+<p>to</p>
+    <blockquote>
+    any non-const, non-reference type
+    </blockquote>
+
+<p><i>[Redmond: previous proposed resolution was &quot;any non-const,
+non-volatile, non-reference type&quot;.  Got rid of the &quot;non-volatile&quot;.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>
+Two resolutions were originally proposed: one that partially
+specialized std::allocator for const types, and one that said an
+allocator's value type may not be const.  The LWG chose the second.
+The first wouldn't be appropriate, because allocators are intended for
+use by containers, and const value types don't work in containers.
+Encouraging the use of allocators with const value types would only
+lead to unsafe code.
+</p>
+<p>
+The original text for proposed resolution 2 was modified so that it
+also forbids volatile types and reference types.
+</p>
+
+<p><i>[Cura&ccedil;ao: LWG double checked and believes volatile is correctly
+excluded from the PR.]</i></p>
+
+<hr>
 <a name="275"><h3>275.&nbsp;Wrong type in num_get::get() overloads</h3></a><p>
 <b>Section:</b>&nbsp;22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
 <p>
@@ -5994,6 +6631,150 @@ the arguments it was given.
                 ios_base::iostate&amp; err, float&amp; val) const;
 </pre>
 <hr>
+<a name="276"><h3>276.&nbsp;Assignable requirement for container value type overly strict</h3></a><p>
+<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
+<p>
+23.1/3 states that the objects stored in a container must be
+Assignable.  23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
+states that map satisfies all requirements for a container, while in
+the same time defining value_type as pair&lt;const Key, T&gt; - a type
+that is not Assignable.
+</p>
+
+<p>
+It should be noted that there exists a valid and non-contradictory
+interpretation of the current text. The wording in 23.1/3 avoids 
+mentioning value_type, referring instead to &quot;objects stored in a
+container.&quot; One might argue that map does not store objects of
+type map::value_type, but of map::mapped_type instead, and that the
+Assignable requirement applies to map::mapped_type, not
+map::value_type.
+</p>
+
+<p>
+However, this makes map a special case (other containers store objects of
+type value_type) and the Assignable requirement is needlessly restrictive in
+general.
+</p>
+
+<p>
+For example, the proposed resolution of active library issue 
+<a href="lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
+means that no set operations can exploit the fact that the stored
+objects are Assignable.
+</p>
+
+<p>
+This is related to, but slightly broader than, closed issue
+<a href="lwg-closed.html#140">140</a>.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>23.1/3: Strike the trailing part of the sentence:</p>
+    <blockquote>
+    , and the additional requirements of Assignable types from 23.1/3
+    </blockquote>
+<p>so that it reads:</p>
+    <blockquote>
+    -3- The type of objects stored in these components must meet the 
+    requirements of CopyConstructible types (lib.copyconstructible).
+    </blockquote>
+
+<p>23.1/4: Modify to make clear that this requirement is not for all 
+containers.  Change to:</p>
+
+<blockquote>
+-4- Table 64 defines the Assignable requirement.  Some containers 
+require this property of the types to be stored in the container.  T is 
+the type used to instantiate the container. t is a value of T, and u is 
+a value of (possibly const) T.
+</blockquote>
+
+<p>23.1, Table 65: in the first row, change &quot;T is Assignable&quot; to &quot;T is
+CopyConstructible&quot;.</p>
+
+<p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
+
+<blockquote>
+-2- A deque satisfies all of the requirements of a container and of a 
+reversible container (given in tables in lib.container.requirements) and 
+of a sequence, including the optional sequence requirements 
+(lib.sequence.reqmts).  In addition to the requirements on the stored 
+object described in 23.1[lib.container.requirements], the stored object 
+must also meet the requirements of Assignable.  Descriptions are 
+provided here only for operations on deque that are not described in one 
+of these tables or for operations where there is additional semantic 
+information.
+</blockquote>
+
+<p>23.2.2/2:  Add Assignable requirement to specific methods of list.  
+Change to:</p>
+
+<blockquote>
+<p>-2- A list satisfies all of the requirements of a container and of a 
+reversible container (given in two tables in lib.container.requirements) 
+and of a sequence, including most of the the optional sequence 
+requirements (lib.sequence.reqmts). The exceptions are the operator[] 
+and at member functions, which are not provided. 
+
+[Footnote: These member functions are only provided by containers whose 
+iterators are random access iterators. --- end foonote]
+</p>
+
+<p>list does not require the stored type T to be Assignable unless the 
+following methods are instantiated:
+
+[Footnote: Implementors are permitted but not required to take advantage 
+of T's Assignable properties for these methods. -- end foonote]
+</p>
+<pre>
+     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
+     template &lt;class InputIterator&gt;
+       void assign(InputIterator first, InputIterator last);
+     void assign(size_type n, const T&amp; t);
+</pre>
+
+
+<p>Descriptions are provided here only for operations on list that are not 
+described in one of these tables or for operations where there is 
+additional semantic information.</p>
+</blockquote>
+
+<p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
+
+<blockquote>
+-2- A vector satisfies all of the requirements of a container and of a 
+reversible container (given in two tables in lib.container.requirements) 
+and of a sequence, including most of the optional sequence requirements 
+(lib.sequence.reqmts). The exceptions are the push_front and pop_front 
+member functions, which are not provided.  In addition to the 
+requirements on the stored object described in 
+23.1[lib.container.requirements], the stored object must also meet the 
+requirements of Assignable.  Descriptions are provided here only for 
+operations on vector that are not described in one of these tables or 
+for operations where there is additional semantic information.
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>list, set, multiset, map, multimap are able to store non-Assignables.
+However, there is some concern about <tt>list&lt;T&gt;</tt>:
+although in general there's no reason for T to be Assignable, some
+implementations of the member functions <tt>operator=</tt> and
+<tt>assign</tt> do rely on that requirement.  The LWG does not want
+to forbid such implementations.</p>
+
+<p>Note that the type stored in a standard container must still satisfy
+the requirements of the container's allocator; this rules out, for
+example, such types as &quot;const int&quot;.  See issue <a href="lwg-defects.html#274">274</a>
+for more details.
+</p>
+
+<p>In principle we could also relax the &quot;Assignable&quot; requirement for
+individual <tt>vector</tt> member functions, such as
+<tt>push_back</tt>.  However, the LWG did not see great value in such
+selective relaxation.  Doing so would remove implementors' freedom to
+implement <tt>vector::push_back</tt> in terms of
+<tt>vector::insert</tt>.</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="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</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
@@ -6016,6 +6797,54 @@ is unnecessary.
 (20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
 </p>
 <hr>
+<a name="284"><h3>284.&nbsp;unportable example in 20.3.7, p6</h3></a><p>
+<b>Section:</b>&nbsp;20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;26 Dec 2000</p>
+<p>The example in 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
+library function <tt>strcmp()</tt> with the function pointer adapter
+<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
+functions have <tt>extern &quot;C&quot;</tt> or <tt>extern
+&quot;C++&quot;</tt> linkage [17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
+function pointers with different the language linkage specifications
+(7.5 <a href="dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
+well-formed is unspecified.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
+<blockquote>
+  <p>[<i>Example:</i>
+</p>
+  <pre>
+    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), &quot;C&quot;)), &quot;C++&quot;);
+  </pre>
+  <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
+</blockquote>
+
+
+<p>to:</p>
+<blockquote>
+  <p>[<i>Example:</i>
+</p>
+  <pre>
+    int compare(const char*, const char*);
+    replace_if(v.begin(), v.end(),
+               not1(bind2nd(ptr_fun(compare), &quot;abc&quot;)), &quot;def&quot;);
+  </pre>
+  <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
+</blockquote>
+
+<p>Also, remove footnote 215 in that same paragraph.</p>
+
+<p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
+issue deals in part with C and C++ linkage, it was believed to be too
+confusing for the strings in the example to be &quot;C&quot; and &quot;C++&quot;.
+]</i></p>
+
+<p><i>[Redmond: More minor changes.  Got rid of the footnote (which
+seems to make a sweeping normative requirement, even though footnotes
+aren't normative), and changed the sentence after the footnote so that
+it corresponds to the new code fragment.]</i></p>
+
+<hr>
 <a name="285"><h3>285.&nbsp;minor editorial errors in fstream ctors</h3></a><p>
 <b>Section:</b>&nbsp;27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;31 Dec 2000</p>
 <p>27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
@@ -6695,6 +7524,125 @@ Table 82.  However, &lt;cstdio&gt; is mentioned several times within
 section 27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
 
 <hr>
+<a name="310"><h3>310.&nbsp;Is errno a macro?</h3></a><p>
+<b>Section:</b>&nbsp;17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
+  <p>
+  Exactly how should errno be declared in a conforming C++ header?
+  </p>
+
+  <p>
+  The C standard says in 7.1.4 that it is unspecified whether errno is a
+  macro or an identifier with external linkage.  In some implementations
+  it can be either, depending on compile-time options.  (E.g., on
+  Solaris in multi-threading mode, errno is a macro that expands to a
+  function call, but is an extern int otherwise.  &quot;Unspecified&quot; allows
+  such variability.)
+  </p>
+
+  <p>The C++ standard:</p>
+  <ul>
+  <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
+  <li>17.4.3.1.3 footnote 166 says errno is reserved as an external 
+      name (true), and implies that it is an identifier.</li>
+  <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
+      on to say that the contents of of C++ &lt;errno.h&gt; are the
+      same as in C, begging the question.</li>
+  <li>C.2, table 95 lists errno as a macro, without comment.</li>
+  </ul>
+
+  <p>I find no other references to errno.</p>
+
+  <p>We should either explicitly say that errno must be a macro, even
+  though it need not be a macro in C, or else explicitly leave it
+  unspecified.  We also need to say something about namespace std. 
+  A user who includes &lt;cerrno&gt; needs to know whether to write
+  <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
+  else &lt;cerrno&gt; is useless.</p>
+
+  <p>Two acceptable fixes:</p>
+  <ul>
+    <li><p>errno must be a macro. This is trivially satisfied by adding<br>
+        &nbsp;&nbsp;#define errno (::std::errno)<br>
+        to the headers if errno is not already a macro. You then always
+        write errno without any scope qualification, and it always expands
+        to a correct reference. Since it is always a macro, you know to
+        avoid using errno as a local identifer.</p></li>
+    <li><p>errno is in the global namespace. This fix is inferior, because
+        ::errno is not guaranteed to be well-formed.</p></li>
+  </ul>
+
+  <p><i>[
+    This issue was first raised in 1999, but it slipped through 
+    the cracks.
+  ]</i></p>
+<p><b>Proposed resolution:</b></p>
+  <p>Change the Note in section 17.4.1.2p5 from</p>
+
+    <blockquote>
+    Note: the names defined as macros in C include the following:
+    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
+    </blockquote>
+
+  <p>to</p>
+
+    <blockquote>
+    Note: the names defined as macros in C include the following:
+    assert, offsetof, setjmp, va_arg, va_end, and va_start.
+    </blockquote>
+
+  <p>In section 19.3, change paragraph 2 from</p>
+
+    <blockquote>
+    The contents are the same as the Standard C library header
+    &lt;errno.h&gt;.
+    </blockquote>
+
+  <p>to</p>
+
+    <blockquote>
+    The contents are the same as the Standard C library header 
+    &lt;errno.h&gt;, except that errno shall be defined as a macro.
+    </blockquote>
+<p><b>Rationale:</b></p>
+<p>C++ must not leave it up to the implementation to decide whether or
+not a name is a macro; it must explicitly specify exactly which names
+are required to be macros.  The only one that really works is for it
+to be a macro.</p>
+
+<p><i>[Cura&ccedil;ao: additional rationale added.]</i></p>
+
+<hr>
+<a name="311"><h3>311.&nbsp;Incorrect wording in basic_ostream class synopsis</h3></a><p>
+<b>Section:</b>&nbsp;27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
+
+<p>In 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
+
+<pre>
+  // partial specializationss
+  template&lt;class traits&gt;
+    basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
+                                            const char * );
+</pre>
+
+<p>Problems:</p>
+<ul>
+<li>Too many 's's at the end of &quot;specializationss&quot; </li>
+<li>This is an overload, not a partial specialization</li>
+</ul>
+
+<p><b>Proposed resolution:</b></p>
+<p>In the synopsis in 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the 
+<i>// partial specializationss</i> comment.  Also remove the same 
+comment (correctly spelled, but still incorrect) from the synopsis in 
+27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
+</p>
+
+<p><i>[
+Pre-Redmond: added 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
+comment in c++std-lib-8939.
+]</i></p>
+
+<hr>
 <a name="312"><h3>312.&nbsp;Table 27 is missing headers</h3></a><p>
 <b>Section:</b>&nbsp;20 <a href="lib-utilities.html#lib.utilities"> [lib.utilities]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Mar 2001</p>
 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
@@ -6703,6 +7651,388 @@ Memory (lib.memory) but neglects to mention the headers
 <p><b>Proposed resolution:</b></p>
 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
 as &lt;memory&gt;.</p>
+<hr>
+<a name="315"><h3>315.&nbsp;Bad &quot;range&quot; in list::unique complexity</h3></a><p>
+<b>Section:</b>&nbsp;23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
+<p>
+23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
+list::unique as: &quot;If the range (last - first) is not empty, exactly
+(last - first) -1 applications of the corresponding predicate,
+otherwise no applications of the predicate)&quot;.
+</p>
+
+<p>
+&quot;(last - first)&quot; is not a range.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the &quot;range&quot; from (last - first) to [first, last).
+</p>
+<hr>
+<a name="316"><h3>316.&nbsp;Vague text in Table 69</h3></a><p>
+<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
+<p>Table 69 says this about a_uniq.insert(t):</p>
+
+<blockquote>
+inserts t if and only if there is no element in the container with key
+equivalent to the key of t. The bool component of the returned pair 
+indicates whether the insertion takes place and the iterator component of the
+pair points to the element with key equivalent to the key of t.
+</blockquote>
+
+<p>The description should be more specific about exactly how the bool component
+indicates whether the insertion takes place.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the text in question to</p>
+
+<blockquote>
+...The bool component of the returned pair is true if and only if the insertion
+takes place...
+</blockquote>
+<hr>
+<a name="317"><h3>317.&nbsp;Instantiation vs. specialization of facets</h3></a><p>
+<b>Section:</b>&nbsp;22 <a href="lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
+<p>
+The localization section of the standard refers to specializations of
+the facet templates as instantiations even though the required facets
+are typically specialized rather than explicitly (or implicitly)
+instantiated. In the case of ctype&lt;char&gt; and
+ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
+actually required to be specialized. The terminology should be
+corrected to make it clear that the standard doesn't mandate explicit
+instantiation (the term specialization encompasses both explicit
+instantiations and specializations).
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In the following paragraphs, replace all occurrences of the word
+instantiation or instantiations with specialization or specializations,
+respectively:
+</p>
+
+<blockquote>
+22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
+22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
+22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
+Footnote 242.
+</blockquote>
+
+<p>And change the text in 22.1.1.1.1, p4 from</p>
+
+<blockquote>
+    An implementation is required to provide those instantiations
+    for facet templates identified as members of a category, and
+    for those shown in Table 52:
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+    An implementation is required to provide those specializations...
+</blockquote>
+
+<p><i>[Nathan will review these changes, and will look for places where
+explicit specialization is necessary.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>This is a simple matter of outdated language.  The language to
+describe templates was clarified during the standardization process,
+but the wording in clause 22 was never updated to reflect that
+change.</p>
+<hr>
+<a name="318"><h3>318.&nbsp;Misleading comment in definition of numpunct_byname</h3></a><p>
+<b>Section:</b>&nbsp;22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 May 2001</p>
+<p>The definition of the numpunct_byname template contains the following
+comment:</p>
+
+<pre>
+    namespace std {
+        template &lt;class charT&gt;
+        class numpunct_byname : public numpunct&lt;charT&gt; {
+    // this class is specialized for char and wchar_t.
+        ...
+</pre>
+
+<p>There is no documentation of the specializations and it seems
+conceivable that an implementation will not explicitly specialize the
+template at all, but simply provide the primary template.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Remove the comment from the text in 22.2.3.2 and from the proposed
+resolution of library issue <a href="lwg-defects.html#228">228</a>.</p>
+<hr>
+<a name="319"><h3>319.&nbsp;Storage allocation wording confuses &quot;Required behavior&quot;, &quot;Requires&quot;</h3></a><p>
+<b>Section:</b>&nbsp;18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;15 May 2001</p>
+<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that &quot;Required
+behavior&quot; elements describe &quot;the semantics of a function definition
+provided by either the implementation or a C++ program.&quot;</p>
+
+<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that &quot;Requires&quot;
+elements describe &quot;the preconditions for calling the function.&quot;</p>
+
+<p>In the sections noted below, the current wording specifies
+&quot;Required Behavior&quot; for what are actually preconditions, and thus
+should be specified as &quot;Requires&quot;.</p>
+
+<p><b>Proposed resolution:</b></p>
+
+<p>In 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
+<blockquote>
+  <p>Required behavior: accept a value of ptr that is null or that was
+  returned by an earlier call ...</p>
+</blockquote>
+<p>to:</p>
+<blockquote>
+  <p>Requires: the value of ptr is null or the value returned by an
+  earlier call ...</p>
+</blockquote>
+
+<p>In 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
+<blockquote>
+  <p>Required behavior: accept a value of ptr that is null or that was
+  returned by an earlier call ...</p>
+</blockquote>
+<p>to:</p>
+<blockquote>
+  <p>Requires: the value of ptr is null or the value returned by an
+  earlier call ...</p>
+</blockquote>
+
+<hr>
+<a name="321"><h3>321.&nbsp;Typo in num_get</h3></a><p>
+<b>Section:</b>&nbsp;22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Kevin Djang&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
+<p>
+Section 22.2.2.1.2 at p7 states that &quot;A length specifier is added to
+the conversion function, if needed, as indicated in Table 56.&quot;
+However, Table 56 uses the term &quot;length modifier&quot;, not &quot;length
+specifier&quot;.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 22.2.2.1.2 at p7, change the text &quot;A length specifier is added ...&quot;
+to be &quot;A length modifier is added ...&quot;
+</p>
+<p><b>Rationale:</b></p>
+<p>C uses the term &quot;length modifier&quot;.  We should be consistent.</p>
+<hr>
+<a name="322"><h3>322.&nbsp;iterator and const_iterator should have the same value type</h3></a><p>
+<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
+<p>
+It's widely assumed that, if X is a container,
+iterator_traits&lt;X::iterator&gt;::value_type and
+iterator_traits&lt;X::const_iterator&gt;::value_type should both be
+X::value_type.  However, this is nowhere stated.  The language in
+Table 65 is not precise about the iterators' value types (it predates
+iterator_traits), and could even be interpreted as saying that
+iterator_traits&lt;X::const_iterator&gt;::value_type should be &quot;const
+X::value_type&quot;.
+</p>
+
+<p>Related issue: <a href="lwg-closed.html#279">279</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<p>In Table 65 (&quot;Container Requirements&quot;), change the return type for
+X::iterator to &quot;iterator type whose value type is T&quot;.  Change the
+return type for X::const_iterator to &quot;constant iterator type whose
+value type is T&quot;.</p>
+<p><b>Rationale:</b></p>
+<p>
+This belongs as a container requirement, rather than an iterator
+requirement, because the whole notion of iterator/const_iterator
+pairs is specific to containers' iterator.
+</p>
+<p>
+It is existing practice that (for example) 
+iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
+is &quot;int&quot;, rather than &quot;const int&quot;.  This is consistent with
+the way that const pointers are handled: the standard already 
+requires that iterator_traits&lt;const int*&gt;::value_type is int.
+</p>
+<hr>
+<a name="327"><h3>327.&nbsp;Typo in time_get facet in table 52</h3></a><p>
+<b>Section:</b>&nbsp;22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Tiki Wan&nbsp; <b>Date:</b>&nbsp;06 Jul 2001</p>
+<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
+<tt>time_get_byname</tt> are listed incorrectly in table 52,
+required instantiations.  In both cases the second template
+parameter is given as OutputIterator.  It should instead be
+InputIterator, since these are input facets.</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In table 52, required instantiations, in 
+22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
+<pre>
+    time_get&lt;wchar_t, OutputIterator&gt;
+    time_get_byname&lt;wchar_t, OutputIterator&gt;
+</pre>
+<p>to</p>
+<pre>
+    time_get&lt;wchar_t, InputIterator&gt;
+    time_get_byname&lt;wchar_t, InputIterator&gt;
+</pre>
+
+<p><i>[Redmond: Very minor change in proposed resolution.  Original had
+a typo, wchart instead of wchar_t.]</i></p>
+
+<hr>
+<a name="328"><h3>328.&nbsp;Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3></a><p>
+<b>Section:</b>&nbsp;22.2.6.2.2 <a href="lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;07 Jul 2001</p>
+<p>The sprintf format string , &quot;%.01f&quot; (that's the digit one), in the
+description of the do_put() member functions of the money_put facet in
+22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
+for values of type long double, and second, the precision of 01
+doesn't seem to make sense. What was most likely intended was
+&quot;%.0Lf&quot;., that is a precision of zero followed by the L length
+modifier.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the format string to &quot;%.0Lf&quot;.</p>
+<p><b>Rationale:</b></p>
+<p>Fixes an obvious typo</p>
+<hr>
+<a name="331"><h3>331.&nbsp;bad declaration of destructor for ios_base::failure</h3></a><p>
+<b>Section:</b>&nbsp;27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;23 Aug 2001</p>
+<p>
+With the change in 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state
+   &quot;An implementation may strengthen the exception-specification for a 
+    non-virtual function by removing listed exceptions.&quot;
+(issue <a href="lwg-defects.html#119">119</a>)
+and the following declaration of ~failure() in ios_base::failure
+</p>
+<pre>
+    namespace std {
+       class ios_base::failure : public exception {
+       public:
+           ...
+           virtual ~failure();
+           ...
+       };
+     }
+</pre>
+<p>the class failure cannot be implemented since in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty
+exception specification:</p>
+<pre>
+    namespace std {
+       class exception {
+       public:
+         ...
+         virtual ~exception() throw();
+         ...
+       };
+     }
+</pre>
+<p><b>Proposed resolution:</b></p>
+<p>Remove the declaration of ~failure().</p>
+<p><b>Rationale:</b></p>
+<p>The proposed resolution is consistent with the way that destructors
+of other classes derived from <tt>exception</tt> are handled.</p>
+<hr>
+<a name="335"><h3>335.&nbsp;minor issue with char_traits, table 37</h3></a><p>
+<b>Section:</b>&nbsp;21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;06 Sep 2001</p>
+<p>
+Table 37, in 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
+as:
+</p>
+<pre>
+  X::assign(c,d)   assigns c = d.
+</pre>
+
+<p>And para 1 says:</p>
+
+<blockquote>
+ [...] c and d denote values of type CharT [...]
+</blockquote>
+
+<p>
+Naturally, if c and d are <i>values</i>, then the assignment is
+(effectively) meaningless. It's clearly intended that (in the case of
+assign, at least), 'c' is intended to be a reference type.
+</p>
+
+<p>I did a quick survey of the four implementations I happened to have
+lying around, and sure enough they all have signatures:</p>
+<pre>
+    assign( charT&amp;, const charT&amp; );
+</pre>
+
+<p>(or the equivalent). It's also described this way in Nico's book.
+(Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
+and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add the following to 21.1.1 para 1:</p>
+<blockquote>
+ r denotes an lvalue of CharT
+</blockquote>
+
+<p>and change the description of assign in the table to:</p>
+<pre>
+  X::assign(r,d)   assigns r = d
+</pre>
+<hr>
+<a name="337"><h3>337.&nbsp;replace_copy_if's template parameter should be InputIterator</h3></a><p>
+<b>Section:</b>&nbsp;25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;07 Sep 2001</p>
+<p>From c++std-edit-876:</p>
+
+<p>
+In section 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
+parameter of template replace_copy_if should be &quot;InputIterator&quot;
+instead of &quot;Iterator&quot;.  According to 17.3.2.1 <a href="lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
+parameter name conveys real normative meaning.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
+<hr>
+<a name="345"><h3>345.&nbsp;type tm in &lt;cwchar&gt;</h3></a><p>
+<b>Section:</b>&nbsp;21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Clark Nelson&nbsp; <b>Date:</b>&nbsp;19 Oct 2001</p>
+<p>
+C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
+declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
+&lt;cwchar&gt;. Is this omission intentional or accidental?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In section 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add &quot;tm&quot; to table 48.</p>
+<hr>
+<a name="346"><h3>346.&nbsp;Some iterator member functions should be const</h3></a><p>
+<b>Section:</b>&nbsp;24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
+<p>Iterator member functions and operators that do not change the state
+of the iterator should be defined as const member functions or as
+functions that take iterators either by const reference or by
+value. The standard does not explicitly state which functions should
+be const.  Since this a fairly common mistake, the following changes
+are suggested to make this explicit.</p>
+
+<p>The tables almost indicate constness properly through naming: r
+for non-const and a,b for const iterators. The following changes
+make this more explicit and also fix a couple problems.</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
+&quot;In the following sections, a and b denote values of X...&quot; to
+&quot;In the following sections, a and b denote values of type const X...&quot;.</p>
+
+<p>In Table 73, change</p>
+<pre>
+    a-&gt;m   U&amp;         ...
+</pre>
+
+<p>to</p>
+
+<pre>
+    a-&gt;m   const U&amp;   ...
+    r-&gt;m   U&amp;         ...
+</pre>
+
+<p>In Table 73 expression column, change</p>
+
+<pre>
+    *a = t
+</pre>
+
+<p>to</p>
+
+<pre>
+    *r = t
+</pre>
+
+<p><i>[Redmond: The container requirements should be reviewed to see if
+the same problem appears there.]</i></p>
+
 <p>----- End of document -----</p>
 </body>
 </html>
-- 
cgit v1.1