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/ChangeLog

+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.
+
 2002-07-18  Brendan Kehoe  <brendan@zen.org>
 
 	* bits/slice_array.h (_DEFINE_VALARRAY_OPERATOR): Fix typo of

libstdc++-v3/docs/html/23_containers/howto.html

@@ -27,7 +27,7 @@
    <li><a href="#4">&quot;Hinting&quot; during insertion</a>
    <li><a href="#5">Bitmasks and string arguments</a>
    <li><a href="#6"><code>std::list::size()</code> is O(n)!</a>
-   <li><a href="#7">Memory management for vectors</a>
+   <li><a href="#7">Space overhead management for vectors</a>
 </ul>
 
 <hr>
@@ -434,17 +434,19 @@
    </p>
 
 <hr>
-<h2><a name="7">Memory management for vectors</h2>
+<h2><a name="7">Space overhead management for vectors</h2>
    <p>In
       <a href="http://gcc.gnu.org/ml/libstdc++/2002-04/msg00105.html">this
       message to the list</a>, Daniel Kostecky announced work on an
       alternate form of <code>std::vector</code> that would support hints
-      about free store management.  The design was also described, along
-      with possible implementation choices.
-   </p>
-   <p>The first alpha release was announced
-      <a href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00048.html">recently</a>
-      and the releases themselves are available at
+      on the number of elements to be over-allocated.  The design was also
+      described, along with possible implementation choices.
+   </p>
+   <p>The first two alpha releases were announced
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00048.html">here</a>
+      and
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00111.html">here</a>.
+      The releases themselves are available at
       <a href="http://www.kotelna.sk/dk/sw/caphint/">
       http://www.kotelna.sk/dk/sw/caphint/</a>.
    </p>

libstdc++-v3/docs/html/abi.txt

+
+===========================
+
+See http://gcc.gnu.org/ml/libstdc++/2002-07/msg00054.html for why this
+document exists, why it's incomplete, and what needs to be done still.
+
+===========================
+
+2002-07-01 Benjamin Kosnik
+
+Description of the libstdc++ ABI.
+
+I. What is an ABI? What's covered? What's not?
+
+- What's the deal with C++? Why can't different compiler's object
+  files link with each other? Bug? Feature?
+
+- scope of document, of use to system integrators.
+
+- compilation includes and linked library binary must match up..
+
+- library ABI, compiler ABI different (but effects)
+
+- GNU C++ does not have a compiler command line option to switch
+  between various different C++ ABIs. For instance, there is no way to
+  switch between the gcc-3.0.x ABI, gcc-3.1.x ABI, and the gcc-3.2.x
+  ABI during compilation. Other C++ compilers do allow this, and some
+  g++ command line options may change the ABI (-fno-exceptions, see
+  the complete list), but there is no version switch. Sorry. The GNU
+  Project recommends that
+
+- shared library only, static is immutable.
+
+- Minimum environment that supports a versioned ABI: what's needed?  A
+  supported dynamic linker, a GNU linker of sufficient vintage to
+  understand demangled C++ name globbing (ld), a shared executable
+  compiled with g++, and shared libraries (libgcc_s, libstdc++-v3)
+  compiled by a compiler (g++) with a compatible ABI. Phew.
+
+  On top of all that, an additional constraint: libstdc++ did not
+  attempt to version symbols (or age gracefully, really) until version
+  3.1.0. 
+
+  Most modern Linux and BSD versions, particularly ones using
+  gcc-3.1.x tools, will meet the requirements above.
+
+- What configure options impact symbol versioning?
+  There is only one: --enable-symvers. For more information see:
+  http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html
+
+  In particular, libstdc++-v3/acinclude.m4 has a macro called
+  GLIBCPP_ENABLE_SYMVERS that defaults to yes (or the argument passed
+  in via --enable-symvers=foo). At that point, the macro attempts to
+  make sure that all the requirement for symbol versioning are in
+  place. For more information, please consult acinclude.m4. 
+
+- How can I tell if symbol versioning is, indeed, active? 
+
+  When the GNU C++ library is being built with symbol versioning on,
+  you should see the following at configure time for libstdc++-v3:
+
+checking versioning on shared library symbols... gnu
+
+  If you don't see this line in the configure output, or if this line
+  appears but the last word is 'no', then you are out of luck.
+
+  If the compiler is pre-installed, a quick way to test is to compile
+  the following (or any) simple C++ file:
+
+#include <iostream>
+
+int main()
+{ std::cout << "hello" << std::endl; return 0; }
+
+%g++ hello.cc -o hello.out
+%nm hello.out
+
+If you see symbols in the resulting output with "GLIBCPP_3.x" as part
+of the name, then the executable is versioned. Here's an example:
+
+         U _ZNSt8ios_base4InitC1Ev@@GLIBCPP_3.1
+
+
+
+
+
+
+II. ABI changes
+
+- (anything) changing size of an exported symbol
+
+- (anything) changing alignment of an exported symbol
+
+- (anything) changing the layout of an exported symbol
+
+- (anything) changing mangling on an exported symbol
+
+- (anything) adding or deleting an exported symbol
+
+
+III. Versioning
+
+- include files
+
+  - versioning headers with version, why necessary
+    (need to control member/non-member functions, add delete files)
+
+- shared library binaries
+
+  - release versions
+
+  - libtool versions
+
+  - when does so version get a bump? what are the options?
+
+  - how is the link map used?  
+
+  - in an non-abi breaking minor release, how are symbols added?
+    removed?
+
+  - in an abi-breaking major release, what happens? symbol fall back
+
+
+IV. Testing ABI changes
+
+- 'make check-abi'??
+
+- other ABI checkers
+
+
+V. Issues not directly addressed, and possible suggestions
+
+- what to do about multi-ABI systems (nathan scenario)?
+
+  - compatibility libs
+
+  --enable-version-specific-runtime-libs
+
+  - Alexandre Oliva proposal to have extended name attributes, modify ld
+ 
+  - directory-level versioning
+
+- wrapping C++ API's n "C" to use the C ABI.
+
+
+V. References
+
+ABIcheck, a vauge idea of checking ABI compatibility
+http://abicheck.sourceforge.net/
+
+C++ ABI reference
+http://www.codesourcery.com/cxx-abi/
+
+Intel ABI documentation
+"Intel® Compilers for Linux* -Compatibility with the GNU Compilers"
+(included in icc 6.0)
+
+Sun Solaris 2.9 docs
+Linker and Libraries Guide (document 816-1386)
+C++ Migration Guide (document 816-2459)
+http://docs.sun.com/db/prod/solaris.9
+http://docs.sun.com/?p=/doc/816-1386&a=load
+
+Ulrich Drepper, "ELF Symbol Versioning"
+http://people.redhat.com/drepper/symbol-versioning
+

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>

libstdc++-v3/include/bits/char_traits.h

@@ -46,9 +46,13 @@
 
 namespace std 
 {
-  /// 21.1.2 Basis for explicit _Traits specialization 
-  /// NB: That for any given actual character type this definition is
-  /// probably wrong.
+  // 21.1.2
+  /**
+   *  @brief  Basis for explicit traits specializations.
+   *
+   *  @note  For any given actual character type, this definition is
+   *  probably wrong.
+  */
   template<class _CharT>
     struct char_traits
     {

libstdc++-v3/include/bits/deque.tcc

@@ -516,7 +516,7 @@ template <typename _Tp, typename _Alloc>
 // Nothing seems to actually use this.  According to the pattern followed by
 // the rest of the SGI code, it would be called by the deprecated insert(pos)
 // function, but that has been replaced.  We'll take our time removing this
-// anyhow; mark for 3.3.  -pme
+// anyhow; mark for 3.4.  -pme
 template <typename _Tp, typename _Alloc>
   typename deque<_Tp,_Alloc>::iterator 
   deque<_Tp,_Alloc>::

libstdc++-v3/include/bits/stl_alloc.h

@@ -75,7 +75,7 @@
  *  @endif
  *
  *  @note The @c reallocate member functions have been deprecated for 3.2
- *        and will be removed in 3.3.  You must define @c _GLIBCPP_DEPRECATED
+ *        and will be removed in 3.4.  You must define @c _GLIBCPP_DEPRECATED
  *        to make this visible in 3.2; see c++config.h.
  *
  *  The canonical description of these classes is in docs/html/ext/howto.html
@@ -221,7 +221,8 @@ namespace std
   /**
    *  @if maint
    *  This is used primarily (only?) in _Alloc_traits and other places to
-   *  help provide the _Alloc_type typedef.
+   *  help provide the _Alloc_type typedef.  All it does is forward the
+   *  requests after some minimal checking.
    *
    *  This is neither "standard"-conforming nor "SGI".  The _Alloc parameter
    *  must be "SGI" style.
@@ -620,8 +621,10 @@ namespace std
 
 
   /**
-   *  This is a "standard" allocator, as per [20.4].  The private _Alloc is
-   *  "SGI" style.  (See comments at the top of stl_alloc.h.)
+   *  @brief  The "standard" allocator, as per [20.4].
+   *
+   *  The private _Alloc is "SGI" style.  (See comments at the top
+   *  of stl_alloc.h.)
    *
    *  The underlying allocator behaves as follows.
    *  - if __USE_MALLOC then

libstdc++-v3/include/bits/stl_deque.h

@@ -1034,7 +1034,7 @@ public:
    *  of a %deque this operation can be done in constant time.  You should
    *  consider using push_front(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -1078,7 +1078,7 @@ public:
    *  of a %deque this operation can be done in constant time.  You should
    *  consider using push_back(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -1154,7 +1154,7 @@ public:
    *  specified location.  You should consider using
    *  insert(position,value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */

libstdc++-v3/include/bits/stl_iterator.h

@@ -317,6 +317,8 @@ namespace std
 
   // 24.4.2.2.1 back_insert_iterator
   /**
+   *  @brief  Turns assignment into insertion.
+   *
    *  These are output iterators, constructed from a container-of-T.
    *  Assigning a T to the iterator appends it to the container using
    *  push_back.
@@ -387,6 +389,8 @@ namespace std
     { return back_insert_iterator<_Container>(__x); }
 
   /**
+   *  @brief  Turns assignment into insertion.
+   *
    *  These are output iterators, constructed from a container-of-T.
    *  Assigning a T to the iterator prepends it to the container using
    *  push_front.
@@ -456,6 +460,8 @@ namespace std
     { return front_insert_iterator<_Container>(__x); }
 
   /**
+   *  @brief  Turns assignment into insertion.
+   *
    *  These are output iterators, constructed from a container-of-T.
    *  Assigning a T to the iterator inserts it in the container at the
    *  %iterator's position, rather than overwriting the value at that

libstdc++-v3/include/bits/stl_iterator_base_types.h

@@ -68,13 +68,12 @@
 
 namespace std
 {
-  /**
+  /** @{
    *  @defgroup iterator_tags Iterator Tags
    *  These are empty types, used to distinguish different iterators.  The
    *  distinction is not made by what they contain, but simply by what they
    *  are.  Different underlying algorithms can then be used based on the
    *  different operations supporetd by different iterator types.
-   *  @{
   */
   ///  Marking input iterators.
   struct input_iterator_tag {};
@@ -90,6 +89,8 @@ namespace std
 
 
   /**
+   *  @brief  Common %iterator class.
+   *
    *  This class does nothing but define nested typedefs.  %Iterator classes
    *  can inherit from this class to save some work.  The typedefs are then
    *  used in specializations and overloading.
@@ -98,8 +99,9 @@ namespace std
    *  such as @c operator++ and the like.  (How could there be?)
   */
   template<typename _Category, typename _Tp, typename _Distance = ptrdiff_t,
-	   typename _Pointer = _Tp*, typename _Reference = _Tp&>
-    struct iterator {
+           typename _Pointer = _Tp*, typename _Reference = _Tp&>
+    struct iterator
+    {
       /// One of the @link iterator_tags tag types@endlink.
       typedef _Category  iterator_category;
       /// The type "pointed to" by the iterator.

libstdc++-v3/include/bits/stl_list.h

@@ -715,7 +715,7 @@ public:
    *  of a %list this operation can be done in constant time.  You should
    *  consider using push_front(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -758,7 +758,7 @@ public:
    *  of a %list this operation can be done in constant time.  You should
    *  consider using push_back(value_type()) instead.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -810,7 +810,7 @@ public:
    *  Due to the nature of a %list this operation can be done in constant
    *  time, and does not invalidate iterators and references.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */

libstdc++-v3/include/bits/stl_vector.h

@@ -253,7 +253,7 @@ public:
   explicit
   vector(size_type __n)
     : _Base(__n, allocator_type())
-    { _M_finish = uninitialized_fill_n(_M_start, __n, _Tp()); }
+    { _M_finish = uninitialized_fill_n(_M_start, __n, value_type()); }
 
   /**
    *  @brief  %Vector copy constructor.
@@ -489,7 +489,6 @@ public:
   */
   reference
   operator[](size_type __n) { return *(begin() + __n); }
-  // XXX do we need to convert to normal_iterator first?
 
   /**
    *  @brief  Subscript access to the data contained in the %vector.
@@ -545,7 +544,6 @@ public:
   */
   reference
   front() { return *begin(); }
-  // XXX do we need to convert to normal_iterator first?
 
   /**
    *  Returns a read-only (constant) reference to the data at the first
@@ -631,7 +629,7 @@ public:
    *  Note that this kind of operation could be expensive for a vector and if
    *  it is frequently used the user should consider using std::list.
    *
-   *  @note This was deprecated in 3.2 and will be removed in 3.3.  You must
+   *  @note This was deprecated in 3.2 and will be removed in 3.4.  You must
    *        define @c _GLIBCPP_DEPRECATED to make this visible in 3.2; see
    *        c++config.h.
   */
@@ -914,7 +912,7 @@ protected:
 */
 template <typename _Tp, typename _Alloc>
   inline bool
-  operator==(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
+  operator==(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
   {
     return __x.size() == __y.size() &&
            equal(__x.begin(), __x.end(), __y.begin());
@@ -933,7 +931,7 @@ template <typename _Tp, typename _Alloc>
 */
 template <typename _Tp, typename _Alloc>
   inline bool
-  operator<(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
+  operator<(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
   {
     return lexicographical_compare(__x.begin(), __x.end(),
                                    __y.begin(), __y.end());
@@ -941,40 +939,34 @@ template <typename _Tp, typename _Alloc>
 
 /// Based on operator==
 template <typename _Tp, typename _Alloc>
-inline bool
-operator!=(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return !(__x == __y);
-}
+  inline bool
+  operator!=(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return !(__x == __y); }
 
 /// Based on operator<
 template <typename _Tp, typename _Alloc>
-inline bool
-operator>(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return __y < __x;
-}
+  inline bool
+  operator>(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return __y < __x; }
 
 /// Based on operator<
 template <typename _Tp, typename _Alloc>
-inline bool
-operator<=(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return !(__y < __x);
-}
+  inline bool
+  operator<=(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return !(__y < __x); }
 
 /// Based on operator<
 template <typename _Tp, typename _Alloc>
-inline bool
-operator>=(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y) {
-  return !(__x < __y);
-}
+  inline bool
+  operator>=(const vector<_Tp,_Alloc>& __x, const vector<_Tp,_Alloc>& __y)
+  { return !(__x < __y); }
 
 /// See std::vector::swap().
 template <typename _Tp, typename _Alloc>
-inline void swap(vector<_Tp, _Alloc>& __x, vector<_Tp, _Alloc>& __y)
-{
-  __x.swap(__y);
-}
+  inline void
+  swap(vector<_Tp,_Alloc>& __x, vector<_Tp,_Alloc>& __y)
+  { __x.swap(__y); }
 
 } // namespace std
 
 #endif /* __GLIBCPP_INTERNAL_VECTOR_H */
-

libstdc++-v3/libsupc++/exception

@@ -41,11 +41,13 @@ extern "C++" {
 
 namespace std 
 {
-  /** This is the base class for all exceptions thrown by the standard
+  /**
+   *  @brief Base class for all library exceptions.
+   *
+   *  This is the base class for all exceptions thrown by the standard
    *  library, and by certain language expressions.  You are free to derive
    *  your own %exception classes, or use a different hierarchy, or to
    *  throw non-class data (e.g., fundamental types).
-   *  @brief Base class for all library exceptions.
    */
   class exception 
   {

libstdc++-v3/libsupc++/new

@@ -45,7 +45,10 @@ extern "C++" {
 
 namespace std 
 {
-  /** @c bad_alloc (or classes derived from it) is used to report allocation
+  /**
+   *  @brief  Exception possibly thrown by @c new.
+   *
+   *  @c bad_alloc (or classes derived from it) is used to report allocation
    *  errors from the throwing forms of @c new.  */
   class bad_alloc : public exception 
   {

libstdc++-v3/libsupc++/typeinfo

@@ -54,9 +54,12 @@ namespace __cxxabiv1
 
 namespace std 
 {
-  /** The @c type_info class describes type information generated by
+  /**
+   *  @brief  Part of RTTI.
+   *
+   *  The @c type_info class describes type information generated by
    *  an implementation.
-   *  @brief Used in RTTI.  */
+  */
   class type_info 
   {
   public:
@@ -124,7 +127,10 @@ namespace std
 			     void **__obj_ptr) const;
   };
 
-  /** If you attempt an invalid @c dynamic_cast expression, an instance of
+  /**
+   *  @brief  Thrown during incorrect typecasting.
+   *
+   *  If you attempt an invalid @c dynamic_cast expression, an instance of
    *  this class (or something derived from this class) is thrown.  */
   class bad_cast : public exception 
   {