From: Phil Edwards <pme@gcc.gnu.org>
Date: Thu, 23 Jan 2003 23:35:19 +0000 (+0000)
Subject: Bulk documentation merge (copy) from trunk.
X-Git-Tag: releases/gcc-3.2.2~91
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f0dc5008aa853f94dfcb9756ea48bf2770a4d7f8;p=thirdparty%2Fgcc.git

Bulk documentation merge (copy) from trunk.

2003-01-23  Phil Edwards  <pme@gcc.gnu.org>

	Bulk documentation merge (copy) from trunk.
	* docs/doxygen/TODO, docs/doxygen/run_doxygen,
	docs/doxygen/stdheader.cc, docs/doxygen/style.css,
	docs/doxygen/tables.html, docs/doxygen/user.cfg.in,
	docs/html/configopts.html, docs/html/debug.html,
	docs/html/documentation.html, docs/html/explanations.html,
	docs/html/install.html, docs/html/17_intro/contribute.html,
	docs/html/17_intro/howto.html, docs/html/17_intro/license.html,
	docs/html/17_intro/porting.html, docs/html/17_intro/porting.texi,
	docs/html/18_support/howto.html, docs/html/19_diagnostics/howto.html,
	docs/html/20_util/howto.html, docs/html/21_strings/howto.html,
	docs/html/22_locale/codecvt.html, docs/html/22_locale/ctype.html,
	docs/html/22_locale/howto.html, docs/html/22_locale/locale.html,
	docs/html/22_locale/messages.html, docs/html/24_iterators/howto.html,
	docs/html/25_algorithms/howto.html, docs/html/26_numerics/howto.html,
	docs/html/27_io/howto.html, docs/html/ext/lwg-active.html,
	docs/html/ext/lwg-defects.html, docs/html/ext/sgiexts.html,
	docs/html/faq/index.html, docs/html/faq/index.txt:  Merge from trunk.

From-SVN: r61680
---

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index d42a83039230..dad62e70ade6 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,24 @@
+2003-01-23  Phil Edwards  <pme@gcc.gnu.org>
+
+	Bulk documentation merge (copy) from trunk.
+	* docs/doxygen/TODO, docs/doxygen/run_doxygen,
+	docs/doxygen/stdheader.cc, docs/doxygen/style.css,
+	docs/doxygen/tables.html, docs/doxygen/user.cfg.in,
+	docs/html/configopts.html, docs/html/debug.html,
+	docs/html/documentation.html, docs/html/explanations.html,
+	docs/html/install.html, docs/html/17_intro/contribute.html,
+	docs/html/17_intro/howto.html, docs/html/17_intro/license.html,
+	docs/html/17_intro/porting.html, docs/html/17_intro/porting.texi,
+	docs/html/18_support/howto.html, docs/html/19_diagnostics/howto.html,
+	docs/html/20_util/howto.html, docs/html/21_strings/howto.html,
+	docs/html/22_locale/codecvt.html, docs/html/22_locale/ctype.html,
+	docs/html/22_locale/howto.html, docs/html/22_locale/locale.html,
+	docs/html/22_locale/messages.html, docs/html/24_iterators/howto.html,
+	docs/html/25_algorithms/howto.html, docs/html/26_numerics/howto.html,
+	docs/html/27_io/howto.html, docs/html/ext/lwg-active.html,
+	docs/html/ext/lwg-defects.html, docs/html/ext/sgiexts.html,
+	docs/html/faq/index.html, docs/html/faq/index.txt:  Merge from trunk.
+
 2003-01-23  Petur Runolfsson  <peturr02@ru.is>
 
 	PR libstdc++/9322
diff --git a/libstdc++-v3/docs/doxygen/TODO b/libstdc++-v3/docs/doxygen/TODO
index 50ddfe7f2d64..0b6e3d6c00b9 100644
--- a/libstdc++-v3/docs/doxygen/TODO
+++ b/libstdc++-v3/docs/doxygen/TODO
@@ -31,7 +31,11 @@ c24             stl_iterator.h (__normal_iterator, other small TODO bits)
                 stream iterators
 c25             stl_algo.h (lots of stuff)
 c26             <complex>, <valarray>, stl_numeric.h[26.4], Note A
-c27             Untouched
+c27             ios_base callbacks and local storage
+                basic_ios::copyfmt()
+                std_streambuf.h's __copy_streambufs()
+                    " "           _M_* protected memfns (data has been done)
+                fstream and sstream protected members
 
 backward/*      Not scanned by doxygen.  Should it be?  Doubtful.
 
diff --git a/libstdc++-v3/docs/doxygen/run_doxygen b/libstdc++-v3/docs/doxygen/run_doxygen
index d8ca2a914287..6a0806ce4107 100644
--- a/libstdc++-v3/docs/doxygen/run_doxygen
+++ b/libstdc++-v3/docs/doxygen/run_doxygen
@@ -208,7 +208,7 @@ g++ ${srcdir}/docs/doxygen/stdheader.cc -o ./stdheader
 problematic=`egrep -l '#include <.*_.*>' [a-z]*.3`
 for f in $problematic; do
     # this is also slow, but safe and easy to debug
-    oldh=`sed -n '/#include </s/.*<\(.*\)>.*/\1/p' $f`
+    oldh=`sed -n '/fC#include </s/.*<\(.*\)>.*/\1/p' $f`
     newh=`echo $oldh | ./stdheader`
     sed "s=${oldh}=${newh}=" $f > TEMP
     mv TEMP $f
diff --git a/libstdc++-v3/docs/doxygen/stdheader.cc b/libstdc++-v3/docs/doxygen/stdheader.cc
index d705d0169c83..a792592fe2b5 100644
--- a/libstdc++-v3/docs/doxygen/stdheader.cc
+++ b/libstdc++-v3/docs/doxygen/stdheader.cc
@@ -111,6 +111,13 @@ void do_word (std::string const& longheader)
 {
     std::string::size_type start = 0;
 
+    // if it doesn't contain a "." then it's already a std header
+    if (longheader.find(".") == std::string::npos)
+    {
+        std::cout << longheader << '\n';
+        return;
+    }
+
     if (longheader.substr(start,5) == "bits/")  start += 5;
     if ((longheader.substr(start,4) == "stl_") ||
         (longheader.substr(start,4) == "std_"))
diff --git a/libstdc++-v3/docs/doxygen/style.css b/libstdc++-v3/docs/doxygen/style.css
index 5e430053dff1..e527a57c4f20 100644
--- a/libstdc++-v3/docs/doxygen/style.css
+++ b/libstdc++-v3/docs/doxygen/style.css
@@ -1,4 +1,5 @@
 H1 { text-align: center; }
+CAPTION { font-weight: bold }
 A.qindex {}
 A.qindexRef {}
 A.el { text-decoration: none; font-weight: bold }
@@ -10,15 +11,39 @@ DL.el { margin-left: -1cm }
 DIV.fragment { width: 100%; border: none; background-color: #eeeeee }
 DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
 TD.md { background-color: #f2f2ff; font-weight: bold; }
-TD.mdname1 { background-color: #f2f2ff; font-weight: bold; font-style: italic; }
-TD.mdname { background-color: #f2f2ff; font-weight: bold; font-style: italic; width: 600px; }
+TD.mdname1 { background-color: #f2f2ff; font-weight: bold; color: #602020; }
+TD.mdname { background-color: #f2f2ff; font-weight: bold; color: #602020; width: 600px; }
 DIV.groupHeader { margin-left: 16px; margin-top: 12px; margin-bottom: 6px; font-weight: bold }
 DIV.groupText { margin-left: 16px; font-style: italic; font-size: smaller }
-FONT.keyword       { color: #008000 }
-FONT.keywordtype   { color: #604020 }
-FONT.keywordflow   { color: #e08000 }
-FONT.comment       { color: #800000 }
-FONT.preprocessor  { color: #806020 }
-FONT.stringliteral { color: #002080 }
-FONT.charliteral   { color: #008080 }
-.smallertext { font-size: smaller }
+BODY { background: white }
+TD.indexkey { 
+   background-color: #eeeeff; 
+   font-weight: bold; 
+   padding-right  : 10px; 
+   padding-top    : 2px; 
+   padding-left   : 10px; 
+   padding-bottom : 2px; 
+   margin-left    : 0px; 
+   margin-right   : 0px; 
+   margin-top     : 2px; 
+   margin-bottom  : 2px  
+}
+TD.indexvalue { 
+   background-color: #eeeeff; 
+   font-style: italic; 
+   padding-right  : 10px; 
+   padding-top    : 2px; 
+   padding-left   : 10px; 
+   padding-bottom : 2px; 
+   margin-left    : 0px; 
+   margin-right   : 0px; 
+   margin-top     : 2px; 
+   margin-bottom  : 2px  
+}
+span.keyword       { color: #008000 }
+span.keywordtype   { color: #604020 }
+span.keywordflow   { color: #e08000 }
+span.comment       { color: #800000 }
+span.preprocessor  { color: #806020 }
+span.stringliteral { color: #002080 }
+span.charliteral   { color: #008080 }
diff --git a/libstdc++-v3/docs/doxygen/tables.html b/libstdc++-v3/docs/doxygen/tables.html
index 7c340529352b..07e9f3e4b7b3 100644
--- a/libstdc++-v3/docs/doxygen/tables.html
+++ b/libstdc++-v3/docs/doxygen/tables.html
@@ -31,10 +31,6 @@
    are also noted or incorporated.
 </p>
 
-<p class="smallertext">This will probably be incomplete for a while because
-filling out the tables is mind-frothingly boring.  Also, the HTML table
-rendering is ugly.  (Update:  mozilla 0.9.9 looks MUCH better.)</p>
-
 <hr />
 
 <a name="65"><p>
diff --git a/libstdc++-v3/docs/doxygen/user.cfg.in b/libstdc++-v3/docs/doxygen/user.cfg.in
index dff2f3f9d110..3d1f77ab9230 100644
--- a/libstdc++-v3/docs/doxygen/user.cfg.in
+++ b/libstdc++-v3/docs/doxygen/user.cfg.in
@@ -1,4 +1,4 @@
-# Doxyfile 1.2.12
+# Doxyfile 1.3-rc2
 
 # This file describes the settings to be used by the documentation system
 # doxygen (www.doxygen.org) for a project
@@ -43,9 +43,10 @@ OUTPUT_DIRECTORY       = @outdir@
 # documentation generated by doxygen is written. Doxygen will use this 
 # information to generate all constant output in the proper language. 
 # The default language is English, other supported languages are: 
-# Brazilian, Chinese, Croatian, Czech, Danish, Dutch, Finnish, French, 
-# German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, 
-# Portuguese, Romanian, Russian, Slovak, Slovene, Spanish and Swedish.
+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, 
+# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en 
+# (Japanese with english messages), Korean, Norwegian, Polish, Portuguese, 
+# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish and Ukrainian.
 
 OUTPUT_LANGUAGE        = English
 
@@ -66,6 +67,12 @@ EXTRACT_PRIVATE        = YES
 
 EXTRACT_STATIC         = YES
 
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) 
+# defined locally in source files will be included in the documentation. 
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES  = NO
+
 # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all 
 # undocumented members of documented classes, files or namespaces. 
 # If set to NO (the default) these members will be included in the 
@@ -81,6 +88,20 @@ HIDE_UNDOC_MEMBERS     = YES
 
 HIDE_UNDOC_CLASSES     = YES
 
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all 
+# friend (class|struct|union) declarations. 
+# If set to NO (the default) these declarations will be included in the 
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS  = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any 
+# documentation blocks found inside the body of a function. 
+# If set to NO (the default) these blocks will be appended to the 
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS      = NO
+
 # If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will 
 # include brief member descriptions after the members that are listed in 
 # the file and class documentation (similar to JavaDoc). 
@@ -89,7 +110,7 @@ HIDE_UNDOC_CLASSES     = YES
 BRIEF_MEMBER_DESC      = YES
 
 # If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend 
-# the brief description of a member or function before the detailed description. 
+# the brief description of a member or function before the detailed description.
 # Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the 
 # brief descriptions will be completely suppressed.
 
@@ -101,6 +122,14 @@ REPEAT_BRIEF           = YES
 
 ALWAYS_DETAILED_SEC    = YES
 
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited 
+# members of a class in the documentation of that class as if those members were 
+# ordinary class members. Constructors, destructors and assignment operators of 
+# the base classes will not be shown.
+
+INLINE_INHERITED_MEMB  = NO
+# pedwards -- this is useful, but ch27 gets huge
+
 # If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full 
 # path before files name in the file list and in the header files. If set 
 # to NO the shortest path that makes the file name unique will be used.
@@ -121,12 +150,6 @@ STRIP_FROM_PATH        =
 
 INTERNAL_DOCS          = NO
 
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct 
-# doxygen to hide any special comment blocks from generated source code 
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS    = YES
-
 # If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate 
 # file names in lower case letters. If set to YES upper case letters are also 
 # allowed. This is useful if you have classes or files whose names only differ 
@@ -167,6 +190,21 @@ SHOW_INCLUDE_FILES     = YES
 
 JAVADOC_AUTOBRIEF      = NO
 
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen 
+# treat a multi-line C++ special comment block (i.e. a block of //! or /// 
+# comments) as a brief description. This used to be the default behaviour. 
+# The new default is to treat a multi-line C++ comment block as a detailed 
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = YES
+
+# If the DETAILS_AT_TOP tag is set to YES then Doxygen 
+# will output the detailed description near the top, like JavaDoc.
+# If set to NO, the detailed description appears after the member 
+# documentation.
+
+DETAILS_AT_TOP         = NO
+
 # If the INHERIT_DOCS tag is set to YES (the default) then an undocumented 
 # member inherits the documentation from any documented member that it 
 # reimplements.
@@ -183,7 +221,7 @@ INLINE_INFO            = YES
 # alphabetically by member name. If set to NO the members will appear in 
 # declaration order.
 
-SORT_MEMBER_DOCS       = NO
+SORT_MEMBER_DOCS       = YES
 
 # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC 
 # tag is set to YES, then doxygen will reuse the documentation of the first 
@@ -215,6 +253,12 @@ GENERATE_TESTLIST      = NO
 
 GENERATE_BUGLIST       = YES
 
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or 
+# disable (NO) the deprecated list. This list is created by putting 
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
 # This tag can be used to specify a number of aliases that acts 
 # as commands in the documentation. An alias has the form "name=value". 
 # For example adding "sideeffect=\par Side Effects:\n" will allow you to 
@@ -222,7 +266,8 @@ GENERATE_BUGLIST       = YES
 # will result in a user defined paragraph with heading "Side Effects:". 
 # You can put \n's in the value part of an alias to insert newlines.
 
-ALIASES                = "doctodo=@todo\nDoc me!  See docs/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more."
+ALIASES                = "doctodo=@todo\nDoc me!  See docs/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more." \
+                         "isiosfwd=One of the @link s27_2_iosfwd I/O forward declarations @endlink"
 
 # The ENABLED_SECTIONS tag can be used to enable conditional 
 # documentation sections, marked by \if sectionname ... \endif.
@@ -237,7 +282,7 @@ ENABLED_SECTIONS       = @enabled_sections@
 # documentation can be controlled using \showinitializer or \hideinitializer 
 # command in the documentation regardless of this setting.
 
-MAX_INITIALIZER_LINES  = 30
+MAX_INITIALIZER_LINES  = 0
 
 # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources 
 # only. Doxygen will then generate output that is more tailored for C. 
@@ -246,6 +291,13 @@ MAX_INITIALIZER_LINES  = 30
 
 OPTIMIZE_OUTPUT_FOR_C  = NO
 
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources 
+# only. Doxygen will then generate output that is more tailored for Java. 
+# For instance namespaces will be presented as packages, qualified scopes 
+# will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA   = NO
+
 # Set the SHOW_USED_FILES tag to NO to disable the list of files generated 
 # at the bottom of the documentation of classes and structs. If set to YES the 
 # list will mention the files that were used to generate the documentation.
@@ -273,6 +325,13 @@ WARNINGS               = NO
 
 WARN_IF_UNDOCUMENTED   = NO
 
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for 
+# potential errors in the documentation, such as not documenting some 
+# parameters in a documented function, or documenting parameters that 
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR      = NO
+
 # The WARN_FORMAT tag determines the format of the warning messages that 
 # doxygen can produce. The string should contain the $file, $line, and $text 
 # tags, which will be replaced by the file and line number from which the 
@@ -323,14 +382,21 @@ RECURSIVE              = YES
 # excluded from the INPUT source files. This way you can easily exclude a 
 # subdirectory from a directory tree whose root is specified with the INPUT tag.
 
-EXCLUDE                = Makefile CVS
+EXCLUDE                = Makefile \
+                         CVS
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories 
+# that are symbolic links (a Unix filesystem feature) are excluded from the input.
+
+EXCLUDE_SYMLINKS       = NO
 
 # If the value of the INPUT tag contains directories, you can use the 
 # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude 
 # certain files from those directories.
 
 EXCLUDE_PATTERNS       = CVS \
-                         stamp-*
+                         stamp-* \
+                         Makefile
 
 # The EXAMPLE_PATH tag can be used to specify one or more files or 
 # directories that contain example code fragments that are included (see 
@@ -369,7 +435,7 @@ INPUT_FILTER           =
 
 # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using 
 # INPUT_FILTER) will be used to filter the input files when producing source 
-# files to browse.
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
 
 FILTER_SOURCE_FILES    = NO
 
@@ -387,6 +453,12 @@ SOURCE_BROWSER         = YES
 
 INLINE_SOURCES         = NO
 
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct 
+# doxygen to hide any special comment blocks from generated source code 
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS    = YES
+
 # If the REFERENCED_BY_RELATION tag is set to YES (the default) 
 # then for each documented function all documented 
 # functions referencing it will be listed.
@@ -437,6 +509,12 @@ GENERATE_HTML          = @do_html@
 
 HTML_OUTPUT            = @html_output_dir@
 
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION    = .html
+
 # The HTML_HEADER tag can be used to specify a personal HTML header for 
 # each generated HTML page. If it is left blank doxygen will generate a 
 # standard header.
@@ -469,6 +547,20 @@ HTML_ALIGN_MEMBERS     = YES
 
 GENERATE_HTMLHELP      = NO
 
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can 
+# be used to specify the file name of the resulting .chm file. You 
+# can add a path in front of the file if the result should not be 
+# written to the html output dir.
+
+CHM_FILE               = 
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can 
+# be used to specify the location (absolute path including file name) of 
+# the HTML help compiler (hhc.exe). If non empty doxygen will try to run 
+# the html help compiler on the generated index.hhp.
+
+HHC_LOCATION           = 
+
 # If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag 
 # controls if a separate .chi index file is generated (YES) or that 
 # it should be included in the master .chm file (NO).
@@ -528,6 +620,17 @@ GENERATE_LATEX         = NO
 
 LATEX_OUTPUT           = latex
 
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be 
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME         = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to 
+# generate index for LaTeX. If left blank `makeindex' will be used as the 
+# default command name.
+
+MAKEINDEX_CMD_NAME     = makeindex
+
 # If the COMPACT_LATEX tag is set to YES Doxygen generates more compact 
 # LaTeX documents. This may be useful for small projects and may help to 
 # save some trees in general.
@@ -634,10 +737,10 @@ MAN_OUTPUT             = man
 
 MAN_EXTENSION          = .3
 
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output, 
+# then it will generate one additional man file for each entity 
+# documented in the real man page(s). These additional files 
+# only source the real man page, but without them the man command 
 # would be unable to find the correct page. The default is NO.
 
 MAN_LINKS              = NO
@@ -654,6 +757,63 @@ MAN_LINKS              = NO
 
 GENERATE_XML           = NO
 
+# The XML_SCHEMA tag can be used to specify an XML schema, 
+# which can be used by a validating XML parser to check the 
+# syntax of the XML files.
+
+XML_SCHEMA             = 
+
+# The XML_DTD tag can be used to specify an XML DTD, 
+# which can be used by a validating XML parser to check the 
+# syntax of the XML files.
+
+XML_DTD                = 
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will 
+# generate an AutoGen Definitions (see autogen.sf.net) file 
+# that captures the structure of the code including all 
+# documentation. Note that this feature is still experimental 
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF   = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will 
+# generate a Perl module file that captures the structure of 
+# the code including all documentation. Note that this 
+# feature is still experimental and incomplete at the 
+# moment.
+
+GENERATE_PERLMOD       = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate 
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able 
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX          = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be 
+# nicely formatted so it can be parsed by a human reader.  This is useful 
+# if you want to understand what is going on.  On the other hand, if this 
+# tag is set to NO the size of the Perl module output will be much smaller 
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY         = YES
+
+# The names of the make variables in the generated doxyrules.make file 
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. 
+# This is useful so different doxyrules.make files included by the same 
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX = 
+
 #---------------------------------------------------------------------------
 # Configuration options related to the preprocessor   
 #---------------------------------------------------------------------------
@@ -707,6 +867,8 @@ INCLUDE_FILE_PATTERNS  =
 ### completely broken, and the presence of the macros confuses the parser.
 
 PREDEFINED             = _GLIBCPP_DEPRECATED              \
+                         _GLIBCPP_USE_WCHAR_T             \
+                         _GLIBCPP_USE_LONG_LONG           \
                          __glibcpp_class_requires="//"    \
                          __glibcpp_class_requires2="//"   \
                          __glibcpp_class_requires3="//"   \
@@ -745,6 +907,12 @@ GENERATE_TAGFILE       =
 
 ALLEXTERNALS           = YES
 
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed 
+# in the modules index. If set to NO, only the current project's groups will 
+# be listed.
+
+EXTERNAL_GROUPS        = YES
+
 # The PERL_PATH should be the absolute path and name of the perl script 
 # interpreter (i.e. the result of `which perl').
 
@@ -762,6 +930,12 @@ PERL_PATH              = /usr/bin/perl
 
 CLASS_DIAGRAMS         = YES
 
+# If set to YES, the inheritance and collaboration graphs will hide 
+# inheritance and usage relations if the target is undocumented 
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS   = YES
+
 # If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is 
 # available from the path. This tool is part of Graphviz, a graph visualization 
 # toolkit from AT&T and Lucent Bell Labs. The other options in this section 
@@ -788,12 +962,6 @@ COLLABORATION_GRAPH    = YES
 
 TEMPLATE_RELATIONS     = YES
 
-# If set to YES, the inheritance and collaboration graphs will hide 
-# inheritance and usage relations if the target is undocumented 
-# or is not a class.
-
-HIDE_UNDOC_RELATIONS   = YES
-
 # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT 
 # tags are set to YES then doxygen will generate a graph for each documented 
 # file showing the direct and indirect include dependencies of the file with 
@@ -813,6 +981,12 @@ INCLUDED_BY_GRAPH      = YES
 
 GRAPHICAL_HIERARCHY    = YES
 
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images 
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT       = png
+
 # The tag DOT_PATH can be used to specify the path where the dot tool can be 
 # found. If left blank, it is assumed the dot tool can be found on the path.
 
@@ -895,6 +1069,3 @@ BIN_ABSPATH            = /usr/local/bin/
 # the documentation for these projects as well.
 
 EXT_DOC_PATHS          = 
-
-### End of file.
-
diff --git a/libstdc++-v3/docs/html/17_intro/contribute.html b/libstdc++-v3/docs/html/17_intro/contribute.html
index 1ab24b92fb57..17bc65f4ed02 100644
--- a/libstdc++-v3/docs/html/17_intro/contribute.html
+++ b/libstdc++-v3/docs/html/17_intro/contribute.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
 <title>How to contribute</title>
 </head>
diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html
index a8cf3976e13e..9d9bbddb1302 100644
--- a/libstdc++-v3/docs/html/17_intro/howto.html
+++ b/libstdc++-v3/docs/html/17_intro/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
@@ -184,6 +189,9 @@
    <p>For each entry, we give the section number of the standard, when
       applicable.  This list is probably incomplet and inkorrekt.
    </p>
+   <p><strong>[1.9]/11 #3</strong> If <code>isatty(3)</code> is true, then
+      interactive stream support is implied.
+   </p>
    <p><strong>[17.4.4.5]</strong> Non-reentrant functions are probably best
       discussed in the various sections on multithreading (see above).
    </p>
@@ -237,7 +245,8 @@
       here would defeat the purpose.  :-)
    </p>
    <p><strong>[21.1.3.1]/5</strong> I don't really know about the mbstate_t
-      stuff... see the chapter 22 notes for what does exist.
+      stuff... see the <a href="../22_locale/howto.html">chapter 22 notes</a>
+      for what does exist.
    </p>
    <p><strong>[22.*]</strong> Anything and everything we have on locale
       implemenation will be described
@@ -255,8 +264,9 @@
       on the --enable-libio choice:  for stdio, if the written data is
       already in the stdio buffer, the data may be completely safe!
    </p>
-   <p><strong>I/O sentry ctor/dtor</strong> They can perform additional work
-      than the minimum required.  I don't think we're currently taking
+   <p><strong>[27.6.1.1.2]</strong>,<br />
+      <strong>[27.6.2.3]</strong> The I/O sentry ctor and dtor can perform
+      additional work than the minimum required.  We are not currently taking
       advantage of this yet.
    </p>
    <p><strong>[27.7.1.3]/16</strong>,<br />
diff --git a/libstdc++-v3/docs/html/17_intro/license.html b/libstdc++-v3/docs/html/17_intro/license.html
index 7db8aa5f240e..a0a2c9135eae 100644
--- a/libstdc++-v3/docs/html/17_intro/license.html
+++ b/libstdc++-v3/docs/html/17_intro/license.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
diff --git a/libstdc++-v3/docs/html/17_intro/porting.html b/libstdc++-v3/docs/html/17_intro/porting.html
index e791f92dc743..7712c4434b45 100644
--- a/libstdc++-v3/docs/html/17_intro/porting.html
+++ b/libstdc++-v3/docs/html/17_intro/porting.html
@@ -2,60 +2,84 @@
 <head>
 <title>Porting libstdc++-v3</title>
 <meta http-equiv="Content-Type" content="text/html">
-<meta name=description content="Porting libstdc++-v3">
-<meta name=generator content="makeinfo 4.2">
-<link href="http://www.gnu.org/software/texinfo/" rel=generator-home>
+<meta name="description" content="Porting libstdc++-v3">
+<meta name="generator" content="makeinfo 4.3">
+<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
+<!--
+Copyright &copy; 2000, 2001, 2002 Free Software Foundation, Inc.
+
+   <p>Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being "GNU General Public License", the Front-Cover
+texts being (a) (see below), and with the Back-Cover Texts being (b)
+(see below).  A copy of the license is included in the section entitled
+"GNU Free Documentation License".
+
+   <p>(a) The FSF's Front-Cover Text is:
+
+   <p>A GNU Manual
+
+   <p>(b) The FSF's Back-Cover Text is:
+
+   <p>You have freedom to copy and modify this GNU Manual, like GNU
+     software.  Copies published by the Free Software Foundation raise
+     funds for GNU development.-->
 </head>
 <body>
-<h1>Porting libstdc++-v3</h1>
+<h1 class="settitle">Porting libstdc++-v3</h1>
+<div class="node">
 <p><hr>
 Node:<a name="Top">Top</a>,
-Next:<a rel=next accesskey=n href="#Operating%20system">Operating system</a>,
-Up:<a rel=up accesskey=u href="#dir">(dir)</a>
+Next:<a rel="next" accesskey="n" href="#Operating%20system">Operating system</a>,
+Up:<a rel="up" accesskey="u" href="#dir">(dir)</a>
 <br>
+</div>
 
-<h2>Porting libstdc++-v3</h2>
+<h2 class="unnumbered">Porting libstdc++-v3</h2>
 
-<p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
+   <p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
 a new target.
 
-<p>In order to make the GNU C++ library (libstdc++-v3) work with a new
+   <p>In order to make the GNU C++ library (libstdc++-v3) work with a new
 target, you must edit some configuration files and provide some new
 header files.  Unless this is done, libstdc++-v3 will use generic
 settings which may not be correct for your target; even if they are
 correct, they will likely be inefficient.
 
-<p>Before you get started, make sure that you have a working C library on
+   <p>Before you get started, make sure that you have a working C library on
 your target.  The C library need not precisely comply with any
 particular standard, but should generally conform to the requirements
 imposed by the ANSI/ISO standard.
 
-<p>In addition, you should try to verify that the C++ compiler generally
+   <p>In addition, you should try to verify that the C++ compiler generally
 works.  It is difficult to test the C++ compiler without a working
 library, but you should at least try some minimal test cases.
 
-<p>Here are the primary steps required to port the library:
+   <p>Here are the primary steps required to port the library:
 
-<ul>
-<li><a accesskey=1 href="#Operating%20system">Operating system</a>:     Configuring for your operating system. 
-<li><a accesskey=2 href="#CPU">CPU</a>:                  Configuring for your processor chip. 
-<li><a accesskey=3 href="#Character%20types">Character types</a>:      Implementing character classification. 
-<li><a accesskey=4 href="#Thread%20safety">Thread safety</a>:        Implementing atomic operations. 
-<li><a accesskey=5 href="#Numeric%20limits">Numeric limits</a>: 	Implementing numeric limits. 
-<li><a accesskey=6 href="#Libtool">Libtool</a>:              Using libtool. 
-<li><a accesskey=7 href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>:  How you can copy and share this manual. 
+<ul class="menu">
+<li><a accesskey="1" href="#Operating%20system">Operating system</a>:     Configuring for your operating system. 
+<li><a accesskey="2" href="#CPU">CPU</a>:                  Configuring for your processor chip. 
+<li><a accesskey="3" href="#Character%20types">Character types</a>:      Implementing character classification. 
+<li><a accesskey="4" href="#Thread%20safety">Thread safety</a>:        Implementing atomic operations. 
+<li><a accesskey="5" href="#Numeric%20limits">Numeric limits</a>: 	Implementing numeric limits. 
+<li><a accesskey="6" href="#Libtool">Libtool</a>:              Using libtool. 
+<li><a accesskey="7" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>:  How you can copy and share this manual. 
 </ul>
 
+<div class="node">
 <p><hr>
 Node:<a name="Operating%20system">Operating system</a>,
-Next:<a rel=next accesskey=n href="#CPU">CPU</a>,
-Previous:<a rel=previous accesskey=p href="#Top">Top</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#CPU">CPU</a>,
+Previous:<a rel="previous" accesskey="p" href="#Top">Top</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>Operating system</h2>
+<h2 class="chapter">Operating system</h2>
 
-<p>If you are porting to a new operating system (as opposed to a new chip
+   <p>If you are porting to a new operating system (as opposed to a new chip
 using an existing operating system), you will need to create a new
 directory in the <code>config/os</code> hierarchy.  For example, the IRIX
 configuration files are all in <code>config/os/irix</code>.  There is no set
@@ -68,24 +92,25 @@ directory.  The important information is that there needs to be a
 directory under <code>config/os</code> to store the files for your operating
 system.
 
-<p>You'll have to change the <code>configure.target</code> file to ensure that
-your new directory is activated.  Look for the switch statement that
-sets <code>os_include_dir</code>, and add a pattern to handle your operating
-system.  The switch statement switches on only the OS portion of the
-standard target triplet; e.g., the <code>solaris2.8</code> in
-<code>sparc-sun-solaris2.8</code>.
+   <p>You might have to change the <code>configure.target</code> file to ensure that
+your new directory is activated.  Look for the switch statement that sets
+<code>os_include_dir</code>, and add a pattern to handle your operating system
+if the default will not suffice.  The switch statement switches on only
+the OS portion of the standard target triplet; e.g., the <code>solaris2.8</code>
+in <code>sparc-sun-solaris2.8</code>.  If the new directory is named after the
+OS portion of the triplet (the default), then nothing needs to be changed.
 
-<p>The first file to create in this directory, should be called
+   <p>The first file to create in this directory, should be called
 <code>os_defines.h</code>.  This file contains basic macro definitions
 that are required to allow the C++ library to work with your C library. 
 This file should provide macro definitions for <code>__off_t</code>,
 <code>__off64_t</code>, and <code>__ssize_t</code>.  Typically, this just looks
 like:
 
-<br><pre>#define __off_t off_t
-#define __off64_t off64_t
-#define __ssize_t ssize_t
-</pre>
+<pre class="example">     #define __off_t off_t
+     #define __off64_t off64_t
+     #define __ssize_t ssize_t
+     </pre>
 
 <p>You don't have to provide these definitions if your system library
 already defines these types - but the only library known to provide
@@ -94,7 +119,7 @@ provide these macros.  Note that this file does not have to include a
 header file that defines <code>off_t</code>, or the other types; you simply
 have to provide the macros.
 
-<p>In addition, several libstdc++-v3 source files unconditionally define
+   <p>In addition, several libstdc++-v3 source files unconditionally define
 the macro <code>_POSIX_SOURCE</code>.  On many systems, defining this macro
 causes large portions of the C library header files to be eliminated
 at preprocessing time.  Therefore, you may have to <code>#undef</code> this
@@ -109,71 +134,75 @@ need to define.  You will need to add them to the
 target.  It will not work to simply define these macros in
 <code>os_defines.h</code>.
 
-<p>At this time, there is one libstdc++-v3-specific macro which may be
+   <p>At this time, there is one libstdc++-v3-specific macro which may be
 defined.  <code>_G_USING_THUNKS</code> may be defined to 0 to express that the
 port doesn't use thunks (although it is unclear that this is still
 useful since libio support isn't currently working and the g++ v3 ABI
 invalidates the assumption that some ports don't use thunks).
 
-<p>Finally, you should bracket the entire file in an include-guard, like
+   <p>Finally, you should bracket the entire file in an include-guard, like
 this:
 
-<br><pre>#ifndef _GLIBCPP_OS_DEFINES
-#define _GLIBCPP_OS_DEFINES
-...
-#endif
-</pre>
+<pre class="example">     #ifndef _GLIBCPP_OS_DEFINES
+     #define _GLIBCPP_OS_DEFINES
+     ...
+     #endif
+     </pre>
 
-<p>We recommend copying an existing <code>os_defines.h</code> to use as a
+   <p>We recommend copying an existing <code>os_defines.h</code> to use as a
 starting point.
 
+<div class="node">
 <p><hr>
 Node:<a name="CPU">CPU</a>,
-Next:<a rel=next accesskey=n href="#Character%20types">Character types</a>,
-Previous:<a rel=previous accesskey=p href="#Operating%20system">Operating system</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Character%20types">Character types</a>,
+Previous:<a rel="previous" accesskey="p" href="#Operating%20system">Operating system</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>CPU</h2>
+<h2 class="chapter">CPU</h2>
 
-<p>If you are porting to a new chip (as opposed to a new operating system
+   <p>If you are porting to a new chip (as opposed to a new operating system
 running on an existing chip), you will need to create a new directory in the
 <code>config/cpu</code> hierarchy.  Much like the <a href="#Operating%20system">Operating system</a> setup,
 there are no strict rules on how to organize the CPU configuration
 directory, but careful naming choices will allow the configury to find your
 setup files without explicit help.
 
-<p>We recommend that for a target triplet <code>&lt;CPU&gt;-&lt;vendor&gt;-&lt;OS&gt;</code>, you
+   <p>We recommend that for a target triplet <code>&lt;CPU&gt;-&lt;vendor&gt;-&lt;OS&gt;</code>, you
 name your configuration directory <code>config/cpu/&lt;CPU&gt;</code>.  If you do this,
 the configury will find the directory itself.  Otherwise you will need to
 edit the <code>configure.target</code> file and, in the switch statement that sets
 <code>cpu_include_dir</code>, add a pattern to handle your chip.
 
-<p>Note that some chip families share a single configuration directory, for
+   <p>Note that some chip families share a single configuration directory, for
 example, <code>alpha</code>, <code>alphaev5</code>, and <code>alphaev6</code> all use the
 <code>config/cpu/alpha</code> directory, and there is an entry in the
 <code>configure.target</code> switch statement to handle this.
 
-<p>The <code>cpu_include_dir</code> sets default locations for the files controlling
+   <p>The <code>cpu_include_dir</code> sets default locations for the files controlling
 <a href="#Thread%20safety">Thread safety</a> and <a href="#Numeric%20limits">Numeric limits</a>, if the defaults are not
 appropriate for your chip.
 
+<div class="node">
 <p><hr>
 Node:<a name="Character%20types">Character types</a>,
-Next:<a rel=next accesskey=n href="#Thread%20safety">Thread safety</a>,
-Previous:<a rel=previous accesskey=p href="#CPU">CPU</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Thread%20safety">Thread safety</a>,
+Previous:<a rel="previous" accesskey="p" href="#CPU">CPU</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>Character types</h2>
+<h2 class="chapter">Character types</h2>
 
-<p>The library requires that you provide three header files to implement
+   <p>The library requires that you provide three header files to implement
 character classification, analogous to that provided by the C libraries
 <code>&lt;ctype.h&gt;</code> header.  You can model these on the files provided in
 <code>config/os/generic</code>.  However, these files will almost
 certainly need some modification.
 
-<p>The first file to write is <code>ctype_base.h</code>.  This file provides
+   <p>The first file to write is <code>ctype_base.h</code>.  This file provides
 some very basic information about character classification.  The libstdc++-v3
 library assumes that your C library implements <code>&lt;ctype.h&gt;</code> by using
 a table (indexed by character code) containing integers, where each of
@@ -183,33 +212,33 @@ file gives the type of the integer, and the values of the various bit
 masks.  You will have to peer at your own <code>&lt;ctype.h&gt;</code> to figure out
 how to define the values required by this file.
 
-<p>The <code>ctype_base.h</code> header file does not need include guards. 
+   <p>The <code>ctype_base.h</code> header file does not need include guards. 
 It should contain a single <code>struct</code> definition called
 <code>ctype_base</code>.  This <code>struct</code> should contain two type
 declarations, and one enumeration declaration, like this example, taken
 from the IRIX configuration:
 
-<br><pre>struct ctype_base
-{
-  typedef unsigned int 	mask;
-  typedef int* 		__to_type;
-
-  enum
-  {
-    space = _ISspace,
-    print = _ISprint,
-    cntrl = _IScntrl,
-    upper = _ISupper,
-    lower = _ISlower,
-    alpha = _ISalpha,
-    digit = _ISdigit,
-    punct = _ISpunct,
-    xdigit = _ISxdigit,
-    alnum = _ISalnum,
-    graph = _ISgraph
-  };
-};
-</pre>
+<pre class="example">     struct ctype_base
+     {
+       typedef unsigned int 	mask;
+       typedef int* 		__to_type;
+     
+       enum
+       {
+         space = _ISspace,
+         print = _ISprint,
+         cntrl = _IScntrl,
+         upper = _ISupper,
+         lower = _ISlower,
+         alpha = _ISalpha,
+         digit = _ISdigit,
+         punct = _ISpunct,
+         xdigit = _ISxdigit,
+         alnum = _ISalnum,
+         graph = _ISgraph
+       };
+     };
+     </pre>
 
 <p>The <code>mask</code> type is the type of the elements in the table.  If your
 C library uses a table to map lower-case numbers to upper-case numbers,
@@ -219,29 +248,29 @@ penalty, or if your library doesn't implement <code>toupper</code> and
 <code>tolower</code> in this way, you can pick any pointer-to-integer type,
 but you must still define the type.
 
-<p>The enumeration should give definitions for all the values in the above
+   <p>The enumeration should give definitions for all the values in the above
 example, using the values from your native <code>&lt;ctype.h&gt;</code>.  They can
 be given symbolically (as above), or numerically, if you prefer.  You do
 not have to include <code>&lt;ctype.h&gt;</code> in this header; it will always be
 included before <code>ctype_base.h</code> is included.
 
-<p>The next file to write is <code>ctype_noninline.h</code>, which also does
+   <p>The next file to write is <code>ctype_noninline.h</code>, which also does
 not require include guards.  This file defines a few member functions
 that will be included in <code>include/bits/locale_facets.h</code>.  The first
 function that must be written is the <code>ctype&lt;char&gt;::ctype</code>
 constructor.  Here is the IRIX example:
 
-<br><pre>ctype&lt;char&gt;::ctype(const mask* __table = 0, bool __del = false,
-      size_t __refs = 0)
-  : _Ctype_nois&lt;char&gt;(__refs), _M_del(__table != 0 &amp;&amp; __del),
-    _M_toupper(NULL),
-    _M_tolower(NULL),
-    _M_ctable(NULL),
-    _M_table(!__table
-             ? (const mask*) (__libc_attr._ctype_tbl-&gt;_class + 1)
-             : __table)
-  { }
-</pre>
+<pre class="example">     ctype&lt;char&gt;::ctype(const mask* __table = 0, bool __del = false,
+           size_t __refs = 0)
+       : _Ctype_nois&lt;char&gt;(__refs), _M_del(__table != 0 &amp;&amp; __del),
+         _M_toupper(NULL),
+         _M_tolower(NULL),
+         _M_ctable(NULL),
+         _M_table(!__table
+                  ? (const mask*) (__libc_attr._ctype_tbl-&gt;_class + 1)
+                  : __table)
+       { }
+     </pre>
 
 <p>There are two parts of this that you might choose to alter. The first,
 and most important, is the line involving <code>__libc_attr</code>.  That is
@@ -252,140 +281,142 @@ operating system's tables to map upper-case letters to lower-case, and
 vice versa, you should initialize <code>_M_toupper</code> and
 <code>_M_tolower</code> with those tables, in similar fashion.
 
-<p>Now, you have to write two functions to convert from upper-case to
+   <p>Now, you have to write two functions to convert from upper-case to
 lower-case, and vice versa.  Here are the IRIX versions:
 
-<br><pre>char
-ctype&lt;char&gt;::do_toupper(char __c) const
-{ return _toupper(__c); }
-
-char
-ctype&lt;char&gt;::do_tolower(char __c) const
-{ return _tolower(__c); }
-</pre>
+<pre class="example">     char
+     ctype&lt;char&gt;::do_toupper(char __c) const
+     { return _toupper(__c); }
+     
+     char
+     ctype&lt;char&gt;::do_tolower(char __c) const
+     { return _tolower(__c); }
+     </pre>
 
 <p>Your C library provides equivalents to IRIX's <code>_toupper</code> and
 <code>_tolower</code>.  If you initialized <code>_M_toupper</code> and
 <code>_M_tolower</code> above, then you could use those tables instead.
 
-<p>Finally, you have to provide two utility functions that convert strings
+   <p>Finally, you have to provide two utility functions that convert strings
 of characters.  The versions provided here will always work - but you
 could use specialized routines for greater performance if you have
 machinery to do that on your system:
 
-<br><pre>const char*
-ctype&lt;char&gt;::do_toupper(char* __low, const char* __high) const
-{
-  while (__low &lt; __high)
-    {
-      *__low = do_toupper(*__low);
-      ++__low;
-    }
-  return __high;
-}
-
-const char*
-ctype&lt;char&gt;::do_tolower(char* __low, const char* __high) const
-{
-  while (__low &lt; __high)
-    {
-      *__low = do_tolower(*__low);
-      ++__low;
-    }
-  return __high;
-}
-</pre>
-
-<p>You must also provide the <code>ctype_inline.h</code> file, which
+<pre class="example">     const char*
+     ctype&lt;char&gt;::do_toupper(char* __low, const char* __high) const
+     {
+       while (__low &lt; __high)
+         {
+           *__low = do_toupper(*__low);
+           ++__low;
+         }
+       return __high;
+     }
+     
+     const char*
+     ctype&lt;char&gt;::do_tolower(char* __low, const char* __high) const
+     {
+       while (__low &lt; __high)
+         {
+           *__low = do_tolower(*__low);
+           ++__low;
+         }
+       return __high;
+     }
+     </pre>
+
+   <p>You must also provide the <code>ctype_inline.h</code> file, which
 contains a few more functions.  On most systems, you can just copy
 <code>config/os/generic/ctype_inline.h</code> and use it on your system.
 
-<p>In detail, the functions provided test characters for particular
+   <p>In detail, the functions provided test characters for particular
 properties; they are analogous to the functions like <code>isalpha</code> and
 <code>islower</code> provided by the C library.
 
-<p>The first function is implemented like this on IRIX:
+   <p>The first function is implemented like this on IRIX:
 
-<br><pre>bool
-ctype&lt;char&gt;::
-is(mask __m, char __c) const throw()
-{ return (_M_table)[(unsigned char)(__c)] &amp; __m; }
-</pre>
+<pre class="example">     bool
+     ctype&lt;char&gt;::
+     is(mask __m, char __c) const throw()
+     { return (_M_table)[(unsigned char)(__c)] &amp; __m; }
+     </pre>
 
 <p>The <code>_M_table</code> is the table passed in above, in the constructor. 
 This is the table that contains the bitmasks for each character.  The
 implementation here should work on all systems.
 
-<p>The next function is:
+   <p>The next function is:
 
-<br><pre>const char*
-ctype&lt;char&gt;::
-is(const char* __low, const char* __high, mask* __vec) const throw()
-{
-  while (__low &lt; __high)
-    *__vec++ = (_M_table)[(unsigned char)(*__low++)];
-  return __high;
-}
-</pre>
+<pre class="example">     const char*
+     ctype&lt;char&gt;::
+     is(const char* __low, const char* __high, mask* __vec) const throw()
+     {
+       while (__low &lt; __high)
+         *__vec++ = (_M_table)[(unsigned char)(*__low++)];
+       return __high;
+     }
+     </pre>
 
 <p>This function is similar; it copies the masks for all the characters
 from <code>__low</code> up until <code>__high</code> into the vector given by
 <code>__vec</code>.
 
-<p>The last two functions again are entirely generic:
-
-<br><pre>const char*
-ctype&lt;char&gt;::
-scan_is(mask __m, const char* __low, const char* __high) const throw()
-{
-  while (__low &lt; __high &amp;&amp; !this-&gt;is(__m, *__low))
-    ++__low;
-  return __low;
-}
-
-const char*
-ctype&lt;char&gt;::
-scan_not(mask __m, const char* __low, const char* __high) const throw()
-{
-  while (__low &lt; __high &amp;&amp; this-&gt;is(__m, *__low))
-    ++__low;
-  return __low;
-}
-</pre>
-
+   <p>The last two functions again are entirely generic:
+
+<pre class="example">     const char*
+     ctype&lt;char&gt;::
+     scan_is(mask __m, const char* __low, const char* __high) const throw()
+     {
+       while (__low &lt; __high &amp;&amp; !this-&gt;is(__m, *__low))
+         ++__low;
+       return __low;
+     }
+     
+     const char*
+     ctype&lt;char&gt;::
+     scan_not(mask __m, const char* __low, const char* __high) const throw()
+     {
+       while (__low &lt; __high &amp;&amp; this-&gt;is(__m, *__low))
+         ++__low;
+       return __low;
+     }
+     </pre>
+
+<div class="node">
 <p><hr>
 Node:<a name="Thread%20safety">Thread safety</a>,
-Next:<a rel=next accesskey=n href="#Numeric%20limits">Numeric limits</a>,
-Previous:<a rel=previous accesskey=p href="#Character%20types">Character types</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Numeric%20limits">Numeric limits</a>,
+Previous:<a rel="previous" accesskey="p" href="#Character%20types">Character types</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>Thread safety</h2>
+<h2 class="chapter">Thread safety</h2>
 
-<p>The C++ library string functionality requires a couple of atomic
+   <p>The C++ library string functionality requires a couple of atomic
 operations to provide thread-safety.  If you don't take any special
 action, the library will use stub versions of these functions that are
 not thread-safe.  They will work fine, unless your applications are
 multi-threaded.
 
-<p>If you want to provide custom, safe, versions of these functions, there
+   <p>If you want to provide custom, safe, versions of these functions, there
 are two distinct approaches.  One is to provide a version for your CPU,
 using assembly language constructs.  The other is to use the
 thread-safety primitives in your operating system.  In either case, you
 make a file called <code>atomicity.h</code>, and the variable
 <code>ATOMICITYH</code> must point to this file.
 
-<p>If you are using the assembly-language approach, put this code in
+   <p>If you are using the assembly-language approach, put this code in
 <code>config/cpu/&lt;chip&gt;/atomicity.h</code>, where chip is the name of
 your processor (see <a href="#CPU">CPU</a>).  No additional changes are necessary to
 locate the file in this case; <code>ATOMICITYH</code> will be set by default.
 
-<p>If you are using the operating system thread-safety primitives approach,
+   <p>If you are using the operating system thread-safety primitives approach,
 you can also put this code in the same CPU directory, in which case no more
 work is needed to locate the file.  For examples of this approach,
 see the <code>atomicity.h</code> file for IRIX or IA64.
 
-<p>Alternatively, if the primitives are more closely related to the OS
+   <p>Alternatively, if the primitives are more closely related to the OS
 than they are to the CPU, you can put the <code>atomicity.h</code> file in
 the <a href="#Operating%20system">Operating system</a> directory instead.  In this case, you must
 edit <code>configure.target</code>, and in the switch statement that handles
@@ -393,120 +424,126 @@ operating systems, override the <code>ATOMICITYH</code> variable to point to
 the appropriate <code>os_include_dir</code>.  For examples of this approach,
 see the <code>atomicity.h</code> file for AIX.
 
-<p>With those bits out of the way, you have to actually write
+   <p>With those bits out of the way, you have to actually write
 <code>atomicity.h</code> itself.  This file should be wrapped in an
 include guard named <code>_BITS_ATOMICITY_H</code>.  It should define one
 type, and two functions.
 
-<p>The type is <code>_Atomic_word</code>.  Here is the version used on IRIX:
+   <p>The type is <code>_Atomic_word</code>.  Here is the version used on IRIX:
 
-<br><pre>typedef long _Atomic_word;
-</pre>
+<pre class="example">     typedef long _Atomic_word;
+     </pre>
 
 <p>This type must be a signed integral type supporting atomic operations. 
 If you're using the OS approach, use the same type used by your system's
 primitives.  Otherwise, use the type for which your CPU provides atomic
 primitives.
 
-<p>Then, you must provide two functions.  The bodies of these functions
+   <p>Then, you must provide two functions.  The bodies of these functions
 must be equivalent to those provided here, but using atomic operations:
 
-<br><pre>static inline _Atomic_word
-__attribute__ ((__unused__))
-__exchange_and_add (_Atomic_word* __mem, int __val)
-{
-  _Atomic_word __result = *__mem;
-  *__mem += __val;
-  return __result;
-}
-
-static inline void
-__attribute__ ((__unused__))
-__atomic_add (_Atomic_word* __mem, int __val)
-{
-  *__mem += __val;
-}
-</pre>
-
+<pre class="example">     static inline _Atomic_word
+     __attribute__ ((__unused__))
+     __exchange_and_add (_Atomic_word* __mem, int __val)
+     {
+       _Atomic_word __result = *__mem;
+       *__mem += __val;
+       return __result;
+     }
+     
+     static inline void
+     __attribute__ ((__unused__))
+     __atomic_add (_Atomic_word* __mem, int __val)
+     {
+       *__mem += __val;
+     }
+     </pre>
+
+<div class="node">
 <p><hr>
 Node:<a name="Numeric%20limits">Numeric limits</a>,
-Next:<a rel=next accesskey=n href="#Libtool">Libtool</a>,
-Previous:<a rel=previous accesskey=p href="#Thread%20safety">Thread safety</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Libtool">Libtool</a>,
+Previous:<a rel="previous" accesskey="p" href="#Thread%20safety">Thread safety</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>Numeric limits</h2>
+<h2 class="chapter">Numeric limits</h2>
 
-<p>The C++ library requires information about the fundamental data types,
+   <p>The C++ library requires information about the fundamental data types,
 such as the minimum and maximum representable values of each type. 
 You can define each of these values individually, but it is usually
 easiest just to indicate how many bits are used in each of the data
 types and let the library do the rest.  For information about the
 macros to define, see the top of <code>include/bits/std_limits.h</code>.
 
-<p>If you need to define any macros, you can do so in <code>os_defines.h</code>. 
+   <p>If you need to define any macros, you can do so in <code>os_defines.h</code>. 
 However, if all operating systems for your CPU are likely to use the
 same values, you can provide a CPU-specific file instead so that you
 do not have to provide the same definitions for each operating system. 
 To take that approach, create a new file called <code>cpu_limits.h</code> in
 your CPU configuration directory (see <a href="#CPU">CPU</a>).
 
+<div class="node">
 <p><hr>
 Node:<a name="Libtool">Libtool</a>,
-Next:<a rel=next accesskey=n href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
-Previous:<a rel=previous accesskey=p href="#Numeric%20limits">Numeric limits</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
+Previous:<a rel="previous" accesskey="p" href="#Numeric%20limits">Numeric limits</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>Libtool</h2>
+<h2 class="chapter">Libtool</h2>
 
-<p>The C++ library is compiled, archived and linked with libtool. 
+   <p>The C++ library is compiled, archived and linked with libtool. 
 Explaining the full workings of libtool is beyond the scope of this
 document, but there are a few, particular bits that are necessary for
 porting.
 
-<p>Some parts of the libstdc++-v3 library are compiled with the libtool
+   <p>Some parts of the libstdc++-v3 library are compiled with the libtool
 <code>--tags CXX</code> option (the C++ definitions for libtool).  Therefore,
 <code>ltcf-cxx.sh</code> in the top-level directory needs to have the correct
 logic to compile and archive objects equivalent to the C version of libtool,
 <code>ltcf-c.sh</code>.  Some libtool targets have definitions for C but not
 for C++, or C++ definitions which have not been kept up to date.
 
-<p>The C++ run-time library contains initialization code that needs to be
+   <p>The C++ run-time library contains initialization code that needs to be
 run as the library is loaded.  Often, that requires linking in special
 object files when the C++ library is built as a shared library, or
 taking other system-specific actions.
 
-<p>The libstdc++-v3 library is linked with the C version of libtool, even
+   <p>The libstdc++-v3 library is linked with the C version of libtool, even
 though it is a C++ library.  Therefore, the C version of libtool needs to
 ensure that the run-time library initializers are run.  The usual way to
 do this is to build the library using <code>gcc -shared</code>.
 
-<p>If you need to change how the library is linked, look at
+   <p>If you need to change how the library is linked, look at
 <code>ltcf-c.sh</code> in the top-level directory.  Find the switch statement
 that sets <code>archive_cmds</code>.  Here, adjust the setting for your
 operating system.
 
+<div class="node">
 <p><hr>
 Node:<a name="GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
-Previous:<a rel=previous accesskey=p href="#Libtool">Libtool</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Previous:<a rel="previous" accesskey="p" href="#Libtool">Libtool</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
 <br>
+</div>
 
-<h2>GNU Free Documentation License</h2>
+<h2 class="unnumbered">GNU Free Documentation License</h2>
 
 <div align="center">Version 1.1, March 2000</div>
-<br><pre>Copyright &copy; 2000 Free Software Foundation, Inc.
-59 Temple Place, Suite 330, Boston, MA  02111-1307, USA
+<pre class="display">     Copyright &copy; 2000 Free Software Foundation, Inc.
+     59 Temple Place, Suite 330, Boston, MA  02111-1307, USA
+     
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+     </pre>
 
-Everyone is permitted to copy and distribute verbatim copies
-of this license document, but changing it is not allowed.
-</pre>
+     <ol type=1 start=0>
+<li>PREAMBLE
 
-<ol type=1 start=0>
-</p><li>PREAMBLE
-
-<p>The purpose of this License is to make a manual, textbook, or other
+     <p>The purpose of this License is to make a manual, textbook, or other
 written document <dfn>free</dfn> in the sense of freedom: to assure everyone
 the effective freedom to copy and redistribute it, with or without
 modifying it, either commercially or noncommercially.  Secondarily,
@@ -514,12 +551,12 @@ this License preserves for the author and publisher a way to get
 credit for their work, while not being considered responsible for
 modifications made by others.
 
-<p>This License is a kind of "copyleft", which means that derivative
+     <p>This License is a kind of "copyleft", which means that derivative
 works of the document must themselves be free in the same sense.  It
 complements the GNU General Public License, which is a copyleft
 license designed for free software.
 
-<p>We have designed this License in order to use it for manuals for free
+     <p>We have designed this License in order to use it for manuals for free
 software, because free software needs free documentation: a free
 program should come with manuals providing the same freedoms that the
 software does.  But this License is not limited to software manuals;
@@ -527,19 +564,19 @@ it can be used for any textual work, regardless of subject matter or
 whether it is published as a printed book.  We recommend this License
 principally for works whose purpose is instruction or reference.
 
-</p><li>APPLICABILITY AND DEFINITIONS
+     </p><li>APPLICABILITY AND DEFINITIONS
 
-<p>This License applies to any manual or other work that contains a
+     <p>This License applies to any manual or other work that contains a
 notice placed by the copyright holder saying it can be distributed
 under the terms of this License.  The "Document", below, refers to any
 such manual or work.  Any member of the public is a licensee, and is
 addressed as "you".
 
-<p>A "Modified Version" of the Document means any work containing the
+     <p>A "Modified Version" of the Document means any work containing the
 Document or a portion of it, either copied verbatim, or with
 modifications and/or translated into another language.
 
-<p>A "Secondary Section" is a named appendix or a front-matter section of
+     <p>A "Secondary Section" is a named appendix or a front-matter section of
 the Document that deals exclusively with the relationship of the
 publishers or authors of the Document to the Document's overall subject
 (or to related matters) and contains nothing that could fall directly
@@ -550,15 +587,15 @@ connection with the subject or with related matters, or of legal,
 commercial, philosophical, ethical or political position regarding
 them.
 
-<p>The "Invariant Sections" are certain Secondary Sections whose titles
+     <p>The "Invariant Sections" are certain Secondary Sections whose titles
 are designated, as being those of Invariant Sections, in the notice
 that says that the Document is released under this License.
 
-<p>The "Cover Texts" are certain short passages of text that are listed,
+     <p>The "Cover Texts" are certain short passages of text that are listed,
 as Front-Cover Texts or Back-Cover Texts, in the notice that says that
 the Document is released under this License.
 
-<p>A "Transparent" copy of the Document means a machine-readable copy,
+     <p>A "Transparent" copy of the Document means a machine-readable copy,
 represented in a format whose specification is available to the
 general public, whose contents can be viewed and edited directly and
 straightforwardly with generic text editors or (for images composed of
@@ -570,7 +607,7 @@ format whose markup has been designed to thwart or discourage
 subsequent modification by readers is not Transparent.  A copy that is
 not "Transparent" is called "Opaque".
 
-<p>Examples of suitable formats for Transparent copies include plain
+     <p>Examples of suitable formats for Transparent copies include plain
 <small>ASCII</small> without markup, Texinfo input format, LaTeX input format,
 <small>SGML</small> or <small>XML</small> using a publicly available
 <small>DTD</small>, and standard-conforming simple <small>HTML</small> designed
@@ -581,16 +618,16 @@ the <small>DTD</small> and/or processing tools are not generally available,
 and the machine-generated <small>HTML</small> produced by some word
 processors for output purposes only.
 
-<p>The "Title Page" means, for a printed book, the title page itself,
+     <p>The "Title Page" means, for a printed book, the title page itself,
 plus such following pages as are needed to hold, legibly, the material
 this License requires to appear in the title page.  For works in
 formats which do not have any title page as such, "Title Page" means
 the text near the most prominent appearance of the work's title,
 preceding the beginning of the body of the text.
 
-</p><li>VERBATIM COPYING
+     </p><li>VERBATIM COPYING
 
-<p>You may copy and distribute the Document in any medium, either
+     <p>You may copy and distribute the Document in any medium, either
 commercially or noncommercially, provided that this License, the
 copyright notices, and the license notice saying this License applies
 to the Document are reproduced in all copies, and that you add no other
@@ -600,12 +637,12 @@ copying of the copies you make or distribute.  However, you may accept
 compensation in exchange for copies.  If you distribute a large enough
 number of copies you must also follow the conditions in section 3.
 
-<p>You may also lend copies, under the same conditions stated above, and
+     <p>You may also lend copies, under the same conditions stated above, and
 you may publicly display copies.
 
-</p><li>COPYING IN QUANTITY
+     </p><li>COPYING IN QUANTITY
 
-<p>If you publish printed copies of the Document numbering more than 100,
+     <p>If you publish printed copies of the Document numbering more than 100,
 and the Document's license notice requires Cover Texts, you must enclose
 the copies in covers that carry, clearly and legibly, all these Cover
 Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
@@ -617,12 +654,12 @@ Copying with changes limited to the covers, as long as they preserve
 the title of the Document and satisfy these conditions, can be treated
 as verbatim copying in other respects.
 
-<p>If the required texts for either cover are too voluminous to fit
+     <p>If the required texts for either cover are too voluminous to fit
 legibly, you should put the first ones listed (as many as fit
 reasonably) on the actual cover, and continue the rest onto adjacent
 pages.
 
-<p>If you publish or distribute Opaque copies of the Document numbering
+     <p>If you publish or distribute Opaque copies of the Document numbering
 more than 100, you must either include a machine-readable Transparent
 copy along with each Opaque copy, or state in or with each Opaque copy
 a publicly-accessible computer-network location containing a complete
@@ -636,49 +673,49 @@ until at least one year after the last time you distribute an Opaque
 copy (directly or through your agents or retailers) of that edition to
 the public.
 
-<p>It is requested, but not required, that you contact the authors of the
+     <p>It is requested, but not required, that you contact the authors of the
 Document well before redistributing any large number of copies, to give
 them a chance to provide you with an updated version of the Document.
 
-</p><li>MODIFICATIONS
+     </p><li>MODIFICATIONS
 
-<p>You may copy and distribute a Modified Version of the Document under
+     <p>You may copy and distribute a Modified Version of the Document under
 the conditions of sections 2 and 3 above, provided that you release
 the Modified Version under precisely this License, with the Modified
 Version filling the role of the Document, thus licensing distribution
 and modification of the Modified Version to whoever possesses a copy
 of it.  In addition, you must do these things in the Modified Version:
 
-<ol type=A start=1>
-</p><li>Use in the Title Page (and on the covers, if any) a title distinct
+          <ol type=A start=1>
+<li>Use in the Title Page (and on the covers, if any) a title distinct
 from that of the Document, and from those of previous versions
 (which should, if there were any, be listed in the History section
 of the Document).  You may use the same title as a previous version
 if the original publisher of that version gives permission.
 
-<li>List on the Title Page, as authors, one or more persons or entities
+          <li>List on the Title Page, as authors, one or more persons or entities
 responsible for authorship of the modifications in the Modified
 Version, together with at least five of the principal authors of the
 Document (all of its principal authors, if it has less than five).
 
-<li>State on the Title page the name of the publisher of the
+          <li>State on the Title page the name of the publisher of the
 Modified Version, as the publisher.
 
-<li>Preserve all the copyright notices of the Document.
+          <li>Preserve all the copyright notices of the Document.
 
-<li>Add an appropriate copyright notice for your modifications
+          <li>Add an appropriate copyright notice for your modifications
 adjacent to the other copyright notices.
 
-<li>Include, immediately after the copyright notices, a license notice
+          <li>Include, immediately after the copyright notices, a license notice
 giving the public permission to use the Modified Version under the
 terms of this License, in the form shown in the Addendum below.
 
-<li>Preserve in that license notice the full lists of Invariant Sections
+          <li>Preserve in that license notice the full lists of Invariant Sections
 and required Cover Texts given in the Document's license notice.
 
-<li>Include an unaltered copy of this License.
+          <li>Include an unaltered copy of this License.
 
-<li>Preserve the section entitled "History", and its title, and add to
+          <li>Preserve the section entitled "History", and its title, and add to
 it an item stating at least the title, year, new authors, and
 publisher of the Modified Version as given on the Title Page.  If
 there is no section entitled "History" in the Document, create one
@@ -686,7 +723,7 @@ stating the title, year, authors, and publisher of the Document as
 given on its Title Page, then add an item describing the Modified
 Version as stated in the previous sentence.
 
-<li>Preserve the network location, if any, given in the Document for
+          <li>Preserve the network location, if any, given in the Document for
 public access to a Transparent copy of the Document, and likewise
 the network locations given in the Document for previous versions
 it was based on.  These may be placed in the "History" section. 
@@ -694,36 +731,36 @@ You may omit a network location for a work that was published at
 least four years before the Document itself, or if the original
 publisher of the version it refers to gives permission.
 
-<li>In any section entitled "Acknowledgments" or "Dedications",
+          <li>In any section entitled "Acknowledgments" or "Dedications",
 preserve the section's title, and preserve in the section all the
 substance and tone of each of the contributor acknowledgments
 and/or dedications given therein.
 
-<li>Preserve all the Invariant Sections of the Document,
+          <li>Preserve all the Invariant Sections of the Document,
 unaltered in their text and in their titles.  Section numbers
 or the equivalent are not considered part of the section titles.
 
-<li>Delete any section entitled "Endorsements".  Such a section
+          <li>Delete any section entitled "Endorsements".  Such a section
 may not be included in the Modified Version.
 
-<li>Do not retitle any existing section as "Endorsements"
+          <li>Do not retitle any existing section as "Endorsements"
 or to conflict in title with any Invariant Section.
-</ol>
+          </ol>
 
-<p>If the Modified Version includes new front-matter sections or
+     <p>If the Modified Version includes new front-matter sections or
 appendices that qualify as Secondary Sections and contain no material
 copied from the Document, you may at your option designate some or all
 of these sections as invariant.  To do this, add their titles to the
 list of Invariant Sections in the Modified Version's license notice. 
 These titles must be distinct from any other section titles.
 
-<p>You may add a section entitled "Endorsements", provided it contains
+     <p>You may add a section entitled "Endorsements", provided it contains
 nothing but endorsements of your Modified Version by various
 parties--for example, statements of peer review or that the text has
 been approved by an organization as the authoritative definition of a
 standard.
 
-<p>You may add a passage of up to five words as a Front-Cover Text, and a
+     <p>You may add a passage of up to five words as a Front-Cover Text, and a
 passage of up to 25 words as a Back-Cover Text, to the end of the list
 of Cover Texts in the Modified Version.  Only one passage of
 Front-Cover Text and one of Back-Cover Text may be added by (or
@@ -733,20 +770,20 @@ by arrangement made by the same entity you are acting on behalf of,
 you may not add another; but you may replace the old one, on explicit
 permission from the previous publisher that added the old one.
 
-<p>The author(s) and publisher(s) of the Document do not by this License
+     <p>The author(s) and publisher(s) of the Document do not by this License
 give permission to use their names for publicity for or to assert or
 imply endorsement of any Modified Version.
 
-</p><li>COMBINING DOCUMENTS
+     </p><li>COMBINING DOCUMENTS
 
-<p>You may combine the Document with other documents released under this
+     <p>You may combine the Document with other documents released under this
 License, under the terms defined in section 4 above for modified
 versions, provided that you include in the combination all of the
 Invariant Sections of all of the original documents, unmodified, and
 list them all as Invariant Sections of your combined work in its
 license notice.
 
-<p>The combined work need only contain one copy of this License, and
+     <p>The combined work need only contain one copy of this License, and
 multiple identical Invariant Sections may be replaced with a single
 copy.  If there are multiple Invariant Sections with the same name but
 different contents, make the title of each such section unique by
@@ -755,28 +792,28 @@ author or publisher of that section if known, or else a unique number.
 Make the same adjustment to the section titles in the list of
 Invariant Sections in the license notice of the combined work.
 
-<p>In the combination, you must combine any sections entitled "History"
+     <p>In the combination, you must combine any sections entitled "History"
 in the various original documents, forming one section entitled
 "History"; likewise combine any sections entitled "Acknowledgments",
 and any sections entitled "Dedications".  You must delete all sections
 entitled "Endorsements."
 
-</p><li>COLLECTIONS OF DOCUMENTS
+     </p><li>COLLECTIONS OF DOCUMENTS
 
-<p>You may make a collection consisting of the Document and other documents
+     <p>You may make a collection consisting of the Document and other documents
 released under this License, and replace the individual copies of this
 License in the various documents with a single copy that is included in
 the collection, provided that you follow the rules of this License for
 verbatim copying of each of the documents in all other respects.
 
-<p>You may extract a single document from such a collection, and distribute
+     <p>You may extract a single document from such a collection, and distribute
 it individually under this License, provided you insert a copy of this
 License into the extracted document, and follow this License in all
 other respects regarding verbatim copying of that document.
 
-</p><li>AGGREGATION WITH INDEPENDENT WORKS
+     </p><li>AGGREGATION WITH INDEPENDENT WORKS
 
-<p>A compilation of the Document or its derivatives with other separate
+     <p>A compilation of the Document or its derivatives with other separate
 and independent documents or works, in or on a volume of a storage or
 distribution medium, does not as a whole count as a Modified Version
 of the Document, provided no compilation copyright is claimed for the
@@ -785,15 +822,15 @@ License does not apply to the other self-contained works thus compiled
 with the Document, on account of their being thus compiled, if they
 are not themselves derivative works of the Document.
 
-<p>If the Cover Text requirement of section 3 is applicable to these
+     <p>If the Cover Text requirement of section 3 is applicable to these
 copies of the Document, then if the Document is less than one quarter
 of the entire aggregate, the Document's Cover Texts may be placed on
 covers that surround only the Document within the aggregate. 
 Otherwise they must appear on covers around the whole aggregate.
 
-</p><li>TRANSLATION
+     </p><li>TRANSLATION
 
-<p>Translation is considered a kind of modification, so you may
+     <p>Translation is considered a kind of modification, so you may
 distribute translations of the Document under the terms of section 4. 
 Replacing Invariant Sections with translations requires special
 permission from their copyright holders, but you may include
@@ -804,9 +841,9 @@ original English version of this License.  In case of a disagreement
 between the translation and the original English version of this
 License, the original English version will prevail.
 
-</p><li>TERMINATION
+     </p><li>TERMINATION
 
-<p>You may not copy, modify, sublicense, or distribute the Document except
+     <p>You may not copy, modify, sublicense, or distribute the Document except
 as expressly provided for under this License.  Any other attempt to
 copy, modify, sublicense or distribute the Document is void, and will
 automatically terminate your rights under this License.  However,
@@ -814,15 +851,15 @@ parties who have received copies, or rights, from you under this
 License will not have their licenses terminated so long as such
 parties remain in full compliance.
 
-</p><li>FUTURE REVISIONS OF THIS LICENSE
+     </p><li>FUTURE REVISIONS OF THIS LICENSE
 
-<p>The Free Software Foundation may publish new, revised versions
+     <p>The Free Software Foundation may publish new, revised versions
 of the GNU Free Documentation License from time to time.  Such new
 versions will be similar in spirit to the present version, but may
 differ in detail to address new problems or concerns.  See
 <a href="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</a>.
 
-<p>Each version of the License is given a distinguishing version number. 
+     <p>Each version of the License is given a distinguishing version number. 
 If the Document specifies that a particular numbered version of this
 License "or any later version" applies to it, you have the option of
 following the terms and conditions either of that specified version or
@@ -830,57 +867,51 @@ of any later version that has been published (not as a draft) by the
 Free Software Foundation.  If the Document does not specify a version
 number of this License, you may choose any version ever published (not
 as a draft) by the Free Software Foundation.
-</ol>
+        </ol>
 
-<h3>ADDENDUM: How to use this License for your documents</h3>
+<h3 class="unnumberedsec">ADDENDUM: How to use this License for your documents</h3>
 
-<p>To use this License in a document you have written, include a copy of
+   <p>To use this License in a document you have written, include a copy of
 the License in the document and put the following copyright and
 license notices just after the title page:
 
-<br><pre>  Copyright (C)  <var>year</var>  <var>your name</var>.
-  Permission is granted to copy, distribute and/or modify this document
-  under the terms of the GNU Free Documentation License, Version 1.1
-  or any later version published by the Free Software Foundation;
-  with the Invariant Sections being <var>list their titles</var>, with the
-  Front-Cover Texts being <var>list</var>, and with the Back-Cover Texts being <var>list</var>.
-  A copy of the license is included in the section entitled ``GNU
-  Free Documentation License''.
-</pre>
-
-<p>If you have no Invariant Sections, write "with no Invariant Sections"
+<pre class="smallexample">       Copyright (C)  <var>year</var>  <var>your name</var>.
+       Permission is granted to copy, distribute and/or modify this document
+       under the terms of the GNU Free Documentation License, Version 1.1
+       or any later version published by the Free Software Foundation;
+       with the Invariant Sections being <var>list their titles</var>, with the
+       Front-Cover Texts being <var>list</var>, and with the Back-Cover Texts being <var>list</var>.
+       A copy of the license is included in the section entitled ``GNU
+       Free Documentation License''.
+     </pre>
+
+   <p>If you have no Invariant Sections, write "with no Invariant Sections"
 instead of saying which ones are invariant.  If you have no
 Front-Cover Texts, write "no Front-Cover Texts" instead of
 "Front-Cover Texts being <var>list</var>"; likewise for Back-Cover Texts.
 
-<p>If your document contains nontrivial examples of program code, we
+   <p>If your document contains nontrivial examples of program code, we
 recommend releasing these examples in parallel under your choice of
 free software license, such as the GNU General Public License,
 to permit their use in free software.
 
 
+<div class="contents">
 <h2>Table of Contents</h2>
 <ul>
-<li><a name="toc_Top"></a>
-    <a href="#Top">Porting libstdc++-v3</a>
-<li><a name="toc_Operating%20system"></a>
-    <a href="#Operating%20system">Operating system</a>
-<li><a name="toc_CPU"></a>
-    <a href="#CPU">CPU</a>
-<li><a name="toc_Character%20types"></a>
-    <a href="#Character%20types">Character types</a>
-<li><a name="toc_Thread%20safety"></a>
-    <a href="#Thread%20safety">Thread safety</a>
-<li><a name="toc_Numeric%20limits"></a>
-    <a href="#Numeric%20limits">Numeric limits</a>
-<li><a name="toc_Libtool"></a>
-    <a href="#Libtool">Libtool</a>
-<li><a name="toc_GNU%20Free%20Documentation%20License"></a>
-    <a href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>
+<li><a name="toc_Top" href="#Top">Porting libstdc++-v3</a>
+<li><a name="toc_Operating%20system" href="#Operating%20system">Operating system</a>
+<li><a name="toc_CPU" href="#CPU">CPU</a>
+<li><a name="toc_Character%20types" href="#Character%20types">Character types</a>
+<li><a name="toc_Thread%20safety" href="#Thread%20safety">Thread safety</a>
+<li><a name="toc_Numeric%20limits" href="#Numeric%20limits">Numeric limits</a>
+<li><a name="toc_Libtool" href="#Libtool">Libtool</a>
+<li><a name="toc_GNU%20Free%20Documentation%20License" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>
 <ul>
 <li><a href="#GNU%20Free%20Documentation%20License">ADDENDUM: How to use this License for your documents</a>
-</ul>
-</ul>
+</li></ul>
+</li></ul>
+</div>
 
-</body></html>
+   </body></html>
 
diff --git a/libstdc++-v3/docs/html/17_intro/porting.texi b/libstdc++-v3/docs/html/17_intro/porting.texi
index 142a354a0320..24ab682a55c0 100644
--- a/libstdc++-v3/docs/html/17_intro/porting.texi
+++ b/libstdc++-v3/docs/html/17_intro/porting.texi
@@ -8,22 +8,7 @@
 @settitle Porting libstdc++-v3
 @setchapternewpage odd
 
-@ifinfo
-This file explains how to port libstdc++-v3 (the GNU C++ library) to 
-a new target.
-
-Copyright (c) 2000, 2001, 2002 Free Software Foundation, Inc.
-@end ifinfo
-
-@c ---------------------------------------------------------------------
-@c Titlepage
-@c ---------------------------------------------------------------------
-
-@titlepage
-@title Porting libstdc++-v3
-@author Mark Mitchell
-@page
-@vskip 0pt plus 1filll
+@copying
 Copyright @copyright{} 2000, 2001, 2002 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
@@ -43,6 +28,25 @@ texts being (a) (see below), and with the Back-Cover Texts being (b)
      You have freedom to copy and modify this GNU Manual, like GNU
      software.  Copies published by the Free Software Foundation raise
      funds for GNU development.
+@end copying
+
+@ifinfo
+This file explains how to port libstdc++-v3 (the GNU C++ library) to 
+a new target.
+
+@insertcopying
+@end ifinfo
+
+@c ---------------------------------------------------------------------
+@c Titlepage
+@c ---------------------------------------------------------------------
+
+@titlepage
+@title Porting libstdc++-v3
+@author Mark Mitchell
+@page
+@vskip 0pt plus 1filll
+@insertcopying
 @end titlepage
 
 @c ---------------------------------------------------------------------
@@ -102,12 +106,13 @@ directory.  The important information is that there needs to be a
 directory under @file{config/os} to store the files for your operating
 system.
 
-You'll have to change the @file{configure.target} file to ensure that
-your new directory is activated.  Look for the switch statement that
-sets @code{os_include_dir}, and add a pattern to handle your operating
-system.  The switch statement switches on only the OS portion of the
-standard target triplet; e.g., the @code{solaris2.8} in
-@code{sparc-sun-solaris2.8}.
+You might have to change the @file{configure.target} file to ensure that
+your new directory is activated.  Look for the switch statement that sets
+@code{os_include_dir}, and add a pattern to handle your operating system
+if the default will not suffice.  The switch statement switches on only
+the OS portion of the standard target triplet; e.g., the @code{solaris2.8}
+in @code{sparc-sun-solaris2.8}.  If the new directory is named after the
+OS portion of the triplet (the default), then nothing needs to be changed.
 
 The first file to create in this directory, should be called
 @file{os_defines.h}.  This file contains basic macro definitions
diff --git a/libstdc++-v3/docs/html/18_support/howto.html b/libstdc++-v3/docs/html/18_support/howto.html
index c055f999bdcd..c95f956a370a 100644
--- a/libstdc++-v3/docs/html/18_support/howto.html
+++ b/libstdc++-v3/docs/html/18_support/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
diff --git a/libstdc++-v3/docs/html/19_diagnostics/howto.html b/libstdc++-v3/docs/html/19_diagnostics/howto.html
index 07585bb83473..dbfcc9cb054b 100644
--- a/libstdc++-v3/docs/html/19_diagnostics/howto.html
+++ b/libstdc++-v3/docs/html/19_diagnostics/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
@@ -164,6 +169,13 @@
    %</pre>
    <p>The 'Aborted' line comes from the call to abort(), of course.
    </p>
+   <p><strong>UPDATE:</strong> Starting with GCC 3.4, this is the default
+      termination handler; nothing need be done to use it.  To go back to
+      the previous &quot;silent death&quot; method, simply include
+      <code>&lt;exception&gt;<code> and <code>&lt;cstdlib&gt;<code>, and call
+   </p>
+   <pre>
+       std::set_terminate (std::abort);</pre>
    <p>Return <a href="#top">to top of page</a> or
       <a href="../faq/index.html">to the FAQ</a>.
    </p>
diff --git a/libstdc++-v3/docs/html/20_util/howto.html b/libstdc++-v3/docs/html/20_util/howto.html
index 7b7485ed8374..9952849c0fbc 100644
--- a/libstdc++-v3/docs/html/20_util/howto.html
+++ b/libstdc++-v3/docs/html/20_util/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
@@ -167,7 +172,7 @@
       handle member function templates:
    </p>
    <pre>
-    template &lt;class U, class V&gt; pain (const pair&lt;U,V&gt;&amp; p);
+    template &lt;class U, class V&gt; pair (const pair&lt;U,V&gt;&amp; p);
    </pre>
    <p>The compiler will convert as necessary from U to T1 and from
       V to T2 in order to perform the respective initializations.
diff --git a/libstdc++-v3/docs/html/21_strings/howto.html b/libstdc++-v3/docs/html/21_strings/howto.html
index e49a166c0c58..d862467b2a9b 100644
--- a/libstdc++-v3/docs/html/21_strings/howto.html
+++ b/libstdc++-v3/docs/html/21_strings/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
@@ -273,19 +278,32 @@
    #include &lt;algorithm&gt;
    #include &lt;cctype&gt;      // old &lt;ctype.h&gt;
 
-   std::string  s ("Some Kind Of Initial Input Goes Here");
+   struct ToLower
+   {
+     char operator() (char c) const  { return std::tolower(c); }
+   };
 
-   // Change everything into upper case
-   std::transform (s.begin(), s.end(), s.begin(), toupper);
+   struct ToUpper
+   {
+     char operator() (char c) const  { return std::toupper(c); }
+   };
+
+   int main()
+   {
+     std::string  s ("Some Kind Of Initial Input Goes Here");
 
-   // Change everything into lower case
-   std::transform (s.begin(), s.end(), s.begin(), tolower);
+     // Change everything into upper case
+     std::transform (s.begin(), s.end(), s.begin(), ToUpper());
 
-   // Change everything back into upper case, but store the
-   // result in a different string
-   std::string  capital_s;
-   capital_s.reserve(s.size());
-   std::transform (s.begin(), s.end(), capital_s.begin(), tolower); </pre>
+     // Change everything into lower case
+     std::transform (s.begin(), s.end(), s.begin(), ToLower());
+
+     // Change everything back into upper case, but store the
+     // result in a different string
+     std::string  capital_s;
+     capital_s.resize(s.size());
+     std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper());
+   } </pre>
    <p><span class="larger"><strong>Note</strong></span> that these calls all
       involve the global C locale through the use of the C functions
       <code>toupper/tolower</code>.  This is absolutely guaranteed to work --
@@ -296,19 +314,28 @@
       So, if all your input forevermore consists of only those 96
       characters (hahahahahaha), then you're done.
    </p>
-   <p>At minimum, you can write short wrappers like
+   <p><span class="larger"><strong>Note</strong></span> that the
+      <code>ToUpper</code> and <code>ToLower</code> function objects
+      are needed because <code>toupper</code> and <code>tolower</code>
+      are overloaded names (declared in <code>&lt;cctype&gt;</code> and
+      <code>&lt;locale&gt;</code>) so the template-arguments for
+      <code>transform&lt;&gt;</code> cannot be deduced, as explained in
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-11/msg00180.html">this
+      message</a>.  <!-- section 14.8.2.4 clause 16 in ISO 14882:1998
+      if you're into that sort of thing -->
+      At minimum, you can write short wrappers like
    </p>
    <pre>
    char toLower (char c)
    {
-      return tolower(static_cast&lt;unsigned char&gt;(c));
+      return std::tolower(c);
    } </pre>
    <p>The correct method is to use a facet for a particular locale
       and call its conversion functions.  These are discussed more in
       Chapter 22; the specific part is
-      <a href="../22_locale/howto.html#5">here</a>, which shows the
-      final version of this code.  (Thanks to James Kanze for assistance
-      and suggestions on all of this.)
+      <a href="../22_locale/howto.html#7">Correct Transformations</a>,
+      which shows the final version of this code.  (Thanks to James Kanze
+      for assistance and suggestions on all of this.)
    </p>
    <p>Another common operation is trimming off excess whitespace.  Much
       like transformations, this task is trivial with the use of string's
@@ -335,15 +362,78 @@
 
 <hr />
 <h2><a name="5">Making strings of arbitrary character types</a></h2>
-   <p>how to work with char_traits -- in the archives, just need to
-      go through and pull the examples together
+   <p>The <code>std::basic_string</code> is tantalizingly general, in that
+      it is parameterized on the type of the characters which it holds.
+      In theory, you could whip up a Unicode character class and instantiate
+      <code>std::basic_string&lt;my_unicode_char&gt;</code>, or assuming
+      that integers are wider than characters on your platform, maybe just
+      declare variables of type <code>std::basic_string&lt;int&gt;</code>.
+   </p>
+   <p>That's the theory.  Remember however that basic_string has additional
+      type parameters, which take default arguments based on the character
+      type (called CharT here):
+   </p>
+   <pre>
+      template &lt;typename CharT,
+                typename Traits = char_traits&lt;CharT&gt;,
+                typename Alloc = allocator&lt;CharT&gt; &gt;
+      class basic_string { .... };</pre>
+   <p>Now, <code>allocator&lt;CharT&gt;</code> will probably Do The Right
+      Thing by default, unless you need to implement your own allocator
+      for your characters.
+   </p>
+   <p>But <code>char_traits</code> takes more work.  The char_traits
+      template is <em>declared</em> but not <em>defined</em>.
+      That means there is only
+   </p>
+   <pre>
+      template &lt;typename CharT&gt;
+        struct char_traits
+        {
+            static void foo (type1 x, type2 y);
+            ...
+        };</pre>
+   <p>and functions such as char_traits&lt;CharT&gt;::foo() are not
+      actually defined anywhere for the general case.  The C++ standard
+      permits this, because writing such a definition to fit all possible
+      CharT's cannot be done.  (For a time, in earlier versions of GCC,
+      there was a mostly-correct implementation that let programmers be
+      lazy.  :-)  But it broke under many situations, so it was removed.
+      You are no longer allowed to be lazy and non-portable.)
+   </p>
+   <p>The C++ standard also requires that char_traits be specialized for
+      instantiations of <code>char</code> and <code>wchar_t</code>, and it
+      is these template specializations that permit entities like
+      <code>basic_string&lt;char,char_traits&lt;char&gt;&gt;</code> to work.
+   </p>
+   <p>If you want to use character types other than char and wchar_t,
+      such as <code>unsigned char</code> and <code>int</code>, you will
+      need to write specializations for them at the present time.  If you
+      want to use your own special character class, then you have
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00163.html">a lot
+      of work to do</a>, especially if you with to use i18n features
+      (facets require traits information but don't have a traits argument).
+   </p>
+   <p>One example of how to specialize char_traits is given
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00260.html">in
+      this message</a>.  We agree that the way it's used with basic_string
+      (scroll down to main()) doesn't look nice, but that's because
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00236.html">the
+      nice-looking first attempt</a> turned out to
+      <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00242.html">not
+      be conforming C++</a>, due to the rule that CharT must be a POD.
+      (See how tricky this is?)
+   </p>
+   <p>Other approaches were suggested in that same thread, such as providing
+      more specializations and/or some helper types in the library to assist
+      users writing such code.  So far nobody has had the time...
+      <a href="../17_intro/contribute.html">do you?</a>
    </p>
    <p>Return <a href="#top">to top of page</a> or
       <a href="../faq/index.html">to the FAQ</a>.
    </p>
 
 
-
 <!-- ####################################################### -->
 
 <hr />
diff --git a/libstdc++-v3/docs/html/22_locale/codecvt.html b/libstdc++-v3/docs/html/22_locale/codecvt.html
index 64f3856d479f..6acd416fc076 100644
--- a/libstdc++-v3/docs/html/22_locale/codecvt.html
+++ b/libstdc++-v3/docs/html/22_locale/codecvt.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
diff --git a/libstdc++-v3/docs/html/22_locale/ctype.html b/libstdc++-v3/docs/html/22_locale/ctype.html
index 886f83d0739d..3043123f0413 100644
--- a/libstdc++-v3/docs/html/22_locale/ctype.html
+++ b/libstdc++-v3/docs/html/22_locale/ctype.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
diff --git a/libstdc++-v3/docs/html/22_locale/howto.html b/libstdc++-v3/docs/html/22_locale/howto.html
index 106662753d98..d6a340c9e548 100644
--- a/libstdc++-v3/docs/html/22_locale/howto.html
+++ b/libstdc++-v3/docs/html/22_locale/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
@@ -163,18 +168,18 @@
    #include &lt;algorithm&gt;
    #include &lt;cctype&gt;      // old &lt;ctype.h&gt;
 
-   struct Toupper
+   struct ToUpper
    {
-       Toupper(std::locale const&amp; l) : loc(l) {;}
-       char operator() (char c)  { return std::toupper(c,loc); }
+       ToUpper(std::locale const&amp; l) : loc(l) {;}
+       char operator() (char c) const  { return std::toupper(c,loc); }
    private:
        std::locale const&amp; loc;
    };
    
-   struct Tolower
+   struct ToLower
    {
-       Tolower(std::locale const&amp; l) : loc(l) {;}
-       char operator() (char c)  { return std::tolower(c,loc); }
+       ToLower(std::locale const&amp; l) : loc(l) {;}
+       char operator() (char c) const  { return std::tolower(c,loc); }
    private:
        std::locale const&amp; loc;
    };
@@ -182,9 +187,9 @@
    int main ()
    {
       std::string  s("Some Kind Of Initial Input Goes Here");
-      std::locale loc_c("C");
-      Toupper      up(loc_c);
-      Tolower      down(loc_c);
+      std::locale  loc_c("C");
+      ToUpper      up(loc_c);
+      ToLower      down(loc_c);
    
       // Change everything into upper case.
       std::transform(s.begin(), s.end(), s.begin(), up);
@@ -197,6 +202,10 @@
       std::string  capital_s;
       std::transform(s.begin(), s.end(), std::back_inserter(capital_s), up);
    }</pre>
+   <p>The <code>ToUpper</code> and <code>ToLower</code> structs can be
+      generalized for other character types by making <code>operator()</code>
+      a member function template.
+   </p>
    <p>The final version of the code uses <code>bind2nd</code> to eliminate
       the wrapper structs, but the resulting code is tricky.  I have not
       shown it here because no compilers currently available to me will
diff --git a/libstdc++-v3/docs/html/22_locale/locale.html b/libstdc++-v3/docs/html/22_locale/locale.html
index 6816204df8f3..8470a502cf2c 100644
--- a/libstdc++-v3/docs/html/22_locale/locale.html
+++ b/libstdc++-v3/docs/html/22_locale/locale.html
@@ -3,6 +3,7 @@
           PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
@@ -80,7 +81,7 @@ class id
 
 <p>
 Provides an index for looking up specific facets.
-<p>
+</p>
 
 
 <h2>
diff --git a/libstdc++-v3/docs/html/22_locale/messages.html b/libstdc++-v3/docs/html/22_locale/messages.html
index 7497590bd884..b57f45411835 100644
--- a/libstdc++-v3/docs/html/22_locale/messages.html
+++ b/libstdc++-v3/docs/html/22_locale/messages.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
diff --git a/libstdc++-v3/docs/html/24_iterators/howto.html b/libstdc++-v3/docs/html/24_iterators/howto.html
index 4d48cffdcbde..c22df9acf420 100644
--- a/libstdc++-v3/docs/html/24_iterators/howto.html
+++ b/libstdc++-v3/docs/html/24_iterators/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
diff --git a/libstdc++-v3/docs/html/25_algorithms/howto.html b/libstdc++-v3/docs/html/25_algorithms/howto.html
index 65403ca81594..9b2f24812b84 100644
--- a/libstdc++-v3/docs/html/25_algorithms/howto.html
+++ b/libstdc++-v3/docs/html/25_algorithms/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
diff --git a/libstdc++-v3/docs/html/26_numerics/howto.html b/libstdc++-v3/docs/html/26_numerics/howto.html
index 067f59dd0fd7..ef0b36a8eacb 100644
--- a/libstdc++-v3/docs/html/26_numerics/howto.html
+++ b/libstdc++-v3/docs/html/26_numerics/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
diff --git a/libstdc++-v3/docs/html/27_io/howto.html b/libstdc++-v3/docs/html/27_io/howto.html
index 94b0e015fbad..d7a984ec3d58 100644
--- a/libstdc++-v3/docs/html/27_io/howto.html
+++ b/libstdc++-v3/docs/html/27_io/howto.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
@@ -29,6 +34,7 @@
    <li><a href="#7">More on binary I/O</a></li>
    <li><a href="#8">Pathetic performance?  Ditch C.</a></li>
    <li><a href="#9">Threads and I/O</a></li>
+   <li><a href="#10">Which header?</a></li>
 </ul>
 
 <hr />
@@ -553,6 +559,138 @@
       &quot;interesting&quot; problems.
    </p>
 
+<hr />
+<h2><a name="10">Which header?</a></h2>
+   <p>To minimize the time you have to wait on the compiler, it's good to
+      only include the headers you really need.  Many people simply include
+      &lt;iostream&gt; when they don't need to -- and that can <em>penalize
+      your runtime as well.</em>  Here are some tips on which header to use
+      for which situations, starting with the simplest.
+   </p>
+   <p><strong>&lt;iosfwd&gt;</strong> should be included whenever you simply
+      need the <em>name</em> of an I/O-related class, such as
+      &quot;ofstream&quot; or &quot;basic_streambuf&quot;.  Like the name
+      implies, these are forward declarations.  (A word to all you fellow
+      old school programmers:  trying to forward declare classes like
+      &quot;class istream;&quot; won't work.  Look in the iosfwd header if
+      you'd like to know why.)  For example,
+   </p>
+   <pre>
+    #include &lt;iosfwd&gt;
+
+    class MyClass
+    {
+        ....
+        std::ifstream   input_file;
+    };
+
+    extern std::ostream&amp; operator&lt;&lt; (std::ostream&amp;, MyClass&amp;);
+   </pre>
+   <p><strong>&lt;ios&gt;</strong> declares the base classes for the entire
+      I/O stream hierarchy, std::ios_base and std::basic_ios&lt;charT&gt;, the
+      counting types std::streamoff and std::streamsize, the file
+      positioning type std::fpos, and the various manipulators like
+      std::hex, std::fixed, std::noshowbase, and so forth.
+   </p>
+   <p>The ios_base class is what holds the format flags, the state flags,
+      and the functions which change them (setf(), width(), precision(),
+      etc).  You can also store extra data and register callback functions
+      through ios_base, but that has been historically underused.  Anything
+      which doesn't depend on the type of characters stored is consolidated
+      here.
+   </p>
+   <p>The template class basic_ios is the highest template class in the
+      hierarchy; it is the first one depending on the character type, and
+      holds all general state associated with that type:  the pointer to the
+      polymorphic stream buffer, the facet information, etc.
+   </p>
+   <p><strong>&lt;streambuf&gt;</strong> declares the template class
+      basic_streambuf, and two standard instantiations, streambuf and
+      wstreambuf.  If you need to work with the vastly useful and capable
+      stream buffer classes, e.g., to create a new form of storage
+      transport, this header is the one to include.
+   </p>
+   <p><strong>&lt;istream&gt;</strong>/<strong>&lt;ostream&gt;</strong> are
+      the headers to include when you are using the &gt;&gt;/&lt;&lt;
+      interface, or any of the other abstract stream formatting functions.
+      For example,
+   </p>
+   <pre>
+    #include &lt;istream&gt;
+
+    std::ostream&amp; operator&lt;&lt; (std::ostream&amp; os, MyClass&amp; c)
+    {
+       return os &lt;&lt; c.data1() &lt;&lt; c.data2();
+    }
+   </pre>
+   <p>The std::istream and std::ostream classes are the abstract parents of
+      the various concrete implementations.  If you are only using the
+      interfaces, then you only need to use the appropriate interface header.
+   </p>
+   <p><strong>&lt;iomanip&gt;</strong> provides &quot;extractors and inserters
+      that alter information maintained by class ios_base and its dervied
+      classes,&quot; such as std::setprecision and std::setw.  If you need
+      to write expressions like <code>os &lt;&lt; setw(3);</code> or
+      <code>is &gt;&gt; setbase(8);</code>, you must include &lt;iomanip&gt;.
+   </p>
+   <p><strong>&lt;sstream&gt;</strong>/<strong>&lt;fstream&gt;</strong>
+      declare the six stringstream and fstream classes.  As they are the
+      standard concrete descendants of istream and ostream, you will already
+      know about them.
+   </p>
+   <p>Finally, <strong>&lt;iostream&gt;</strong> provides the eight standard
+      global objects (cin, cout, etc).  To do this correctly, this header
+      also provides the contents of the &lt;istream&gt; and &lt;ostream&gt;
+      headers, but nothing else.  The contents of this header look like
+   </p>
+   <pre>
+    #include &lt;ostream&gt;
+    #include &lt;istream&gt;
+
+    namespace std
+    {
+        extern istream cin;
+        extern ostream cout;
+        ....
+
+        // this is explained below
+        <strong>static ios_base::Init __foo;</strong>    // not its real name
+    }
+   </pre>
+   <p>Now, the runtime penalty mentioned previously:  the global objects
+      must be initialized before any of your own code uses them; this is
+      guaranteed by the standard.  Like any other global object, they must
+      be initialized once and only once.  This is typically done with a
+      construct like the one above, and the nested class ios_base::Init is 
+      specified in the standard for just this reason.
+   </p>
+   <p>How does it work?  Because the header is included before any of your
+      code, the <strong>__foo</strong> object is constructed before any of
+      your objects.  (Global objects are built in the order in which they
+      are declared, and destroyed in reverse order.)  The first time the
+      constructor runs, the eight stream objects are set up.
+   </p>
+   <p>The <code>static</code> keyword means that each object file compiled
+      from a source file containing &lt;iostream&gt; will have its own
+      private copy of <strong>__foo</strong>.  There is no specified order
+      of construction across object files (it's one of those pesky NP
+      problems that make life so interesting), so one copy in each object
+      file means that the stream objects are guaranteed to be set up before
+      any of your code which uses them could run, thereby meeting the
+      requirements of the standard.
+   </p>
+   <p>The penalty, of course, is that after the first copy of
+      <strong>__foo</strong> is constructed, all the others are just wasted
+      processor time.  The time spent is merely for an increment-and-test
+      inside a function call, but over several dozen or hundreds of object
+      files, that time can add up.  (It's not in a tight loop, either.)
+   </p>
+   <p>The lesson?  Only include &lt;iostream&gt; when you need to use one of
+      the standard objects in that source file; you'll pay less startup
+      time.  Only include the header files you need to in general; your
+      compile times will go down when there's less parsing work to do.
+   </p>
+
 
 <!-- ####################################################### -->
 
diff --git a/libstdc++-v3/docs/html/configopts.html b/libstdc++-v3/docs/html/configopts.html
index 47eb4637fbe9..aec70a602718 100644
--- a/libstdc++-v3/docs/html/configopts.html
+++ b/libstdc++-v3/docs/html/configopts.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
    <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
@@ -71,23 +76,11 @@ options</a></h1>
  <dd><p>Adds support for named libstdc++ include directory.  For instance,
         the following puts all the libstdc++ headers into a directory
         called &quot;2.97-20001008&quot; instead of the usual
-        &quot;g++-v3&quot;.
+        &quot;c++/(version)&quot;.
      </p>
         <pre>
    --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008</pre> </dd>
 
- <dt><code>--enable-debug  </code></dt>
- <dd><p>The configure script will automatically detect the highest
-        level of optimization that the compiler in use can use.
-        This --enable flag will disable all optimizations and instruct
-        the compiler to emit as much extra debugging information as it
-        can, for use inside GDB.  Note this make command, executed in
-        the build directory, will do much the same thing, without the
-        configuration difference:
-        <code>make CXXFLAGS='-g -O0' all</code>
-     </p>
- </dd>
-
  <dt><code>--enable-cstdio  </code></dt>
  <dd><p>This is an abbreviated form of <code>'--enable-cstdio=stdio'</code>
         (described next). This option can change the library ABI.
@@ -152,6 +145,34 @@ options</a></h1>
      </p>
  </dd>
 
+ <dt><code>--enable-debug  </code></dt>
+ <dd><p>Build separate debug libraries in addition to what is normally built.
+ 	By default, the debug libraries are compiled with 
+        <code> CXXFLAGS='-g3 -O0'</code>
+        , are installed in <code>${libdir}/debug</code>, and have the
+        same names and versioning information as the non-debug
+        libraries. This option is off by default.
+        <p>
+        Note this make command, executed in
+        the build directory, will do much the same thing, without the
+        configuration difference and without building everything twice: 
+        <code>make CXXFLAGS='-g3 -O0' all</code>
+        </p>
+     </p>
+ </dd>
+
+ <dt><code>--enable-debug-flags=FLAGS</code></dt>
+
+ <dd><p>This option is only valid when <code> --enable-debug </code>
+        is also specified, and applies to the debug builds only. With
+        this option, you can pass a specific string of flags to the
+        compiler to use when building the debug versions of libstdc++.
+        FLAGS is a quoted string of options, like
+     </p>
+        <pre>
+  --enable-debug-flags='-g3 -O1 -gdwarf-2'</pre>
+ </dd>
+
  <dt><code>--enable-cxx-flags=FLAGS</code></dt>
  <dd><p>With this option, you can pass a string of -f (functionality)
         flags to the compiler to use when building libstdc++. This
@@ -233,12 +254,13 @@ options</a></h1>
  </dd>
 
  <dt><code>--enable-symvers[=style]  </code></dt>
- <dd><p>In 3.1, tries to turn on symbol versioning in the shared library (if a
-        shared library has been requested).  The only 'style' currently
-        supported is 'gnu' which requires that a recent version of the GNU
-        linker be in use.  With no style given, the configure script will
-        try to guess if the 'gnu' style can be used, and if so, will turn it
-        on.  Hopefully people will volunteer to do other 'style' options.
+ <dd><p>In 3.1 and later, tries to turn on symbol versioning in the
+        shared library (if a shared library has been requested).  The
+        only 'style' currently supported is 'gnu' which requires that
+        a recent version of the GNU linker be in use.  With no style
+        given, the configure script will try to guess if the 'gnu'
+        style can be used, and if so, will turn it on.  Hopefully
+        people will volunteer to do other 'style' options.
      </p>
  </dd>
 </dl>
diff --git a/libstdc++-v3/docs/html/documentation.html b/libstdc++-v3/docs/html/documentation.html
index aba387237472..c0e3cdb112db 100644
--- a/libstdc++-v3/docs/html/documentation.html
+++ b/libstdc++-v3/docs/html/documentation.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <meta name="KEYWORDS" 
   content="libstdc++, homepage, home, C++, library, c++, std, g++, ABI, STL" />
@@ -34,6 +39,8 @@
          - latest version info, recent changes and news</li>
          <li><a href="17_intro/TODO">TODO</a>
          - tasks yet undone</li>
+         <li><a href="faq/index.html">FAQ (HTML)</a>, 
+             <a href="faq/index.txt">FAQ (text)</a></li>
       </ul>
 
 <hr />
@@ -42,6 +49,7 @@
 <ul>
    <li><a href="configopts.html">Configure options</a></li>
    <li><a href="install.html">Getting started: configure, build, install</a>
+   <li><a href="debug.html">Debugging schemes and strategies</a>
    </li>
 </ul>
 
@@ -61,7 +69,7 @@
 <ul>
    <li><a href="libstdc++-html-USERS-3.1/index.html">for the 3.1 release</a>
    </li>
-   <li><a href="libstdc++-html-USERS-3.2/index.html">for the 3.2 release</a>
+   <li><a href="libstdc++-html-USERS-3.2.1/index.html">for the 3.2.1 release</a>
    </li>
    <li><a href="latest-doxygen/index.html">&quot;the latest collection&quot;</a>
        (for the snapshot or later; see the date on the first page)
@@ -203,6 +211,7 @@
      <li><a href="27_io/howto.html#7">More on binary I/O</a></li>
      <li><a href="27_io/howto.html#8">Pathetic performance?  Ditch C.</a></li>
      <li><a href="27_io/howto.html#9">Threads and I/O</a></li>
+     <li><a href="27_io/howto.html#10">Which header?</a></li>
    </ul>
    </li>
 
diff --git a/libstdc++-v3/docs/html/explanations.html b/libstdc++-v3/docs/html/explanations.html
index 7d8196ff84a0..dac57b872887 100644
--- a/libstdc++-v3/docs/html/explanations.html
+++ b/libstdc++-v3/docs/html/explanations.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
    <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html
index c8d33f36f4be..a69d6c67c40c 100644
--- a/libstdc++-v3/docs/html/ext/lwg-active.html
+++ b/libstdc++-v3/docs/html/ext/lwg-active.html
@@ -5,11 +5,11 @@
 <table>
 <tr>
 <td align="left">Doc. no.</td>
-<td align="left">J16/02-0027 = WG21 N1369</td>
+<td align="left">J16/02-0048 = WG21 N1390</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">10 May 2002</td>
+<td align="left">10 Sep 2002</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -17,10 +17,10 @@
 </tr>
 <tr>
 <td align="left">Reply to:</td>
-<td align="left">Matt Austern &lt;austern@research.att.com&gt;</td>
+<td align="left">Matt Austern &lt;austern@apple.com&gt;</td>
 </tr>
 </table>
-<h1>C++ Standard Library Active Issues List (Revision 22)</h1>
+<h1>C++ Standard Library Active Issues List (Revision 23)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
   <ul>
@@ -78,7 +78,7 @@
   <p>Public information as to how to obtain a copy of the C++ Standard,
   join the standards committee, submit an issue, or comment on an issue
   can be found in the C++ FAQ at <a href="http://www.research.att.com/~austern/csc/faq.html">http://www.research.att.com/~austern/csc/faq.html</a>.
-  Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
+  Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c%2B%2B">news:comp.std.c++</a>.
   </p>
 
  <p>For committee members, files available on the committee's private
@@ -88,6 +88,10 @@
   directory as the issues list files.  </p>
 <h2>Revision History</h2>
 <ul>
+<li>R23: 
+Pre-Santa Cruz mailing.  Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
+Moved issues in the TC to TC status.
+</li>
 <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>
@@ -1486,7 +1490,7 @@ specified.  Both resolutions are consistent with the behavior of
 existing implementations.</p>
 <hr>
 <a name="225"><h3>225.&nbsp;std:: algorithms use of other unqualified algorithms</h3></a><p>
-<b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
+<b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
 user namespaces might be found through Koenig lookup?</p>
 <p>For example, a popular standard library implementation includes this
@@ -1586,13 +1590,14 @@ should have any effect.]</i></p>
 
 <p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
 225, 226, and 229.  Their conclusion was that the issues should be
-separated into an LWG portion (Howard will write a proposal), and a
+separated into an LWG portion (Howard's paper, N1387=02-0045), and a
 EWG portion (Dave will write a proposal). The LWG and EWG had
-(separate) discussions of this plan the next day.]</i></p>
+(separate) discussions of this plan the next day.  The proposed
+resolution for this issue is in accordance with Howard's paper.]</i></p>
 
 <hr>
 <a name="226"><h3>226.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p>
-<b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
+<b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
 <p>The issues are:&nbsp;</p>
 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
 algorithm which is specialized to work with his own class template?&nbsp;</p>
@@ -1677,6 +1682,9 @@ not provide an operator&lt;&lt; for std::pair&lt;&gt;.
 
 <p><b>Proposed resolution:</b></p>
 
+<p>Adopt the wording in the <b>Customization Points</b> section of
+Howard Hinnant's paper, N1387=02-0045.</p>
+
 <p><i>[Tokyo: Summary, &quot;There is no conforming way to extend
 std::swap for user defined templates.&quot;&nbsp; The LWG agrees that
 there is a problem.&nbsp; Would like more information before
@@ -1734,13 +1742,14 @@ try to put together a proposal before the next meeting.]</i></p>
 
 <p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
 225, 226, and 229.  Their conclusion was that the issues should be
-separated into an LWG portion (Howard will write a proposal), and a
+separated into an LWG portion (Howard's paper, N1387=02-0045), and a
 EWG portion (Dave will write a proposal). The LWG and EWG had
-(separate) discussions of this plan the next day.]</i></p>
+(separate) discussions of this plan the next day.  The proposed
+resolution is the one proposed by Howard.]</i></p>
 
 <hr>
 <a name="229"><h3>229.&nbsp;Unqualified references of other library entities</h3></a><p>
-<b>Section:</b>&nbsp;17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
+<b>Section:</b>&nbsp;17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
 <p>Throughout the library chapters, the descriptions of library entities refer
 to other library entities without necessarily qualifying the names.</p>
 
@@ -1784,13 +1793,15 @@ but that the wording may not be clear enough to fall under
 
 <p><i>[Cura&ccedil;ao: An LWG-subgroup spent an afternoon working on issues
 225, 226, and 229.  Their conclusion was that the issues should be
-separated into an LWG portion (Howard will write a proposal), and a
+separated into an LWG portion (Howard's paper, N1387=02-0045), and a
 EWG portion (Dave will write a proposal). The LWG and EWG had
-(separate) discussions of this plan the next day.]</i></p>
+(separate) discussions of this plan the next day.  This paper resolves
+issues 225 and 226.  In light of that resolution, the proposed
+resolution for the current issue makes sense.]</i></p>
 
 <hr>
 <a name="231"><h3>231.&nbsp;Precision in iostream?</h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
+<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
 <p>What is the following program supposed to output?</p>
 <pre>#include &lt;iostream&gt;
 
@@ -1831,24 +1842,31 @@ etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
 of the anomalies of printf:-).</p>
 <p><b>Proposed resolution:</b></p>
 <p>
-In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, change 
-&quot;if <tt>(flags &amp; fixed) != 0</tt>&quot; to 
-&quot;if <tt>(flags &amp; floatfield) == fixed ||
-        (flags &amp; floatfield) == scientific</tt>&quot;
+Replace 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following 
+sentence:
 </p>
+<blockquote>
+For conversion from a floating-point type,
+<tt><i>str</i>.precision()</tt> is specified in the conversion
+specification.
+</blockquote>
 <p><b>Rationale:</b></p>
 <p>The floatfield determines whether numbers are formatted as if
 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
 if <tt>scientific</tt> it's %e, and if both bits are set, or 
-neither, it's %e.</p>
+neither, it's %g.</p>
 <p>Turning to the C standard, a precision of 0 is meaningful
-for %f and %e, but not for %g: for %g, precision 0 is taken
-to be the same as precision 1.</p>
-<p>The proposed resolution has the effect that the output of
-the above program will be &quot;1e+00&quot;.</p>
-
-<p><i>[Cura&ccedil;ao: Howard will send Matt improved wording dealing with
-case not covered by current PR.]</i></p>
+for %f and %e.  For %g, precision 0 is taken to be the same as 
+precision 1.</p>
+<p>The proposed resolution has the effect that if neither
+<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
+specifying a precision of 0, which will be internally
+turned into 1.  There's no need to call it out as a special
+case.</p>
+<p>The output of the above program will be &quot;1e+00&quot;.</p>
+
+<p><i>[Post-Cura&ccedil;ao: Howard provided improved wording covering the case
+where precision is 0 and mode is %g.]</i></p>
 
 <hr>
 <a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p>
@@ -2354,6 +2372,28 @@ throw, the string must compare equal to the argument.</li>
 <p>(Not all of these options are mutually exclusive.)</p>
 
 <p><b>Proposed resolution:</b></p>
+<p>NAD/Future</p>
+<p><b>Rationale:</b></p>
+
+<p>Throwing a bad_alloc while trying to construct a message for another
+exception-derived class is not necessarily a bad thing.  And the
+bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
+
+<p>
+The copy constructors of all exception-derived classes already have a
+no throw spec.  Reference 18.6.1,  19.1 and 15.4/13.
+</p>
+
+<p><b>Future:</b></p>
+
+<p>All involved would like to see const char* constructors added, but
+this should probably be done for C++0X as opposed to a DR.</p>
+
+<p>I believe the no throw specs currently decorating these functions
+could be improved by some kind of static no throw spec checking
+mechanism (in a future C++ language).  As they stand, the copy
+constructors might fail via a call to unexpected.  I think what is
+intended here is that the copy constructors can't fail.</p>
 
 <p><i>[Toronto: some LWG members thought this was merely a QoI issue,
 but most believed that it was at least a borderline defect.  There was
@@ -2361,11 +2401,9 @@ more support for nonnormative advice to implementors than for a
 normative change.]</i></p>
 
 <p><i>[Redmond: discussed, without definite conclusion.  Most LWG
-members thought there was a real defect lurking here.  A small group
-(Herb, Kevlin, Howard, Martin, Dave) will try to make a
-recommendation.]</i></p>
-
-<p><i>[Cura&ccedil;ao: Howard will nag the others to work on a recommendation.]</i></p>
+members thought there was a real defect lurking here.  The above
+proposed resolution/rationale is from Howard, Herb, Kevlin,  Martin,
+and Dave.]</i></p>
 
 <hr>
 <a name="258"><h3>258.&nbsp;Missing allocator requirement</h3></a><p>
@@ -2553,7 +2591,7 @@ desirable to provide this feature in a different way.
 
 <hr>
 <a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
+<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
 <p>
 Paragraph 16 mistakenly singles out integral types for inserting 
 thousands_sep() characters.  This conflicts with the syntax for floating 
@@ -2593,8 +2631,8 @@ floating-point input even though this is unambiguously required by the
 standard.
 ]</i></p>
 
-<p><i>[Cura&ccedil;ao: Howard will email Bill and other implementors to try to
-move the issue forward.]</i></p>
+<p><i>[Post-Cura&ccedil;ao: the above proposed resolution is the consensus of
+Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
 
 <hr>
 <a name="283"><h3>283.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p>
@@ -3099,22 +3137,42 @@ note in p24 (below) is that x be empty after the merge which is surely
 unintended in this case.
 </p>
 <p><b>Proposed resolution:</b></p>
+<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
+<blockquote>
 <p>
-Change 23.2.2.4, p23 to:
+23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
+sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
+is a range in which the elements will be sorted in non-decreasing
+order according to the ordering defined by comp; that is, for every
+iterator i in the range other than the first, the condition comp(*i,
+*(i - 1)) will be false.
 </p>
-<blockquote>
-<b>Effects</b>: If &amp;x == this, does nothing; otherwise, merges the
-argument list into the list.
+
+<p>
+24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
+two original ranges, the elements from the original range [begin(),
+end()) always precede the elements from the original range [x.begin(),
+x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
+after the merge.
+</p>
+
+<p>
+25 Complexity: At most size() + x.size() - 1 applications of comp if
+(&amp;x !  = this); otherwise, no applications of comp are performed.  If
+an exception is thrown other than by a comparison there are no
+effects.
+</p>
+
 </blockquote>
 
-<p><i>[Copenhagen: The proposed resolution does not fix all of the
-problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25.  Three different
+<p><i>[Copenhagen: The original proposed resolution did not fix all of
+the problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25.  Three different
 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
 Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, &quot;merges the argument list into the
 list&quot; is excessively vague.]</i></p>
 
-<p><i>[Cura&ccedil;ao: Robert Klarer volunteers to work on this issue.]</i></p>
+<p><i>[Post-Cura&ccedil;ao: Robert Klarer provided new wording.]</i></p>
 
 <hr>
 <a name="304"><h3>304.&nbsp;Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p>
@@ -5283,6 +5341,648 @@ rationale.
   basic_filebuf&lt;charT,traits&gt;* rdbuf();
   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
 </pre>
+<hr>
+<a name="367"><h3>367.&nbsp;remove_copy/remove_copy_if and Input Iterators</h3></a><p>
+<b>Section:</b>&nbsp;25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 May 2002</p>
+<p>
+remove_copy and remove_copy_if (25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>) permit their
+input range to be marked with Input Iterators. However, since two
+operations are required against the elements to copy (comparison and
+assigment), when the input range uses Input Iterators, a temporary
+copy must be taken to avoid dereferencing the iterator twice. This
+therefore requires the value type of the InputIterator to be
+CopyConstructible. If the iterators are at least Forward Iterators,
+then the iterator can be dereferenced twice, or a reference to the
+result maintained, so the temporary is not required.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add &quot;If InputIterator does not meet the requirements of forward
+iterator, then the value type of InputIterator must be copy
+constructible. Otherwise copy constructible is not required.&quot; to
+25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> paragraph 6.
+</p>
+<hr>
+<a name="368"><h3>368.&nbsp;basic_string::replace has two &quot;Throws&quot; paragraphs</h3></a><p>
+<b>Section:</b>&nbsp;21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Jun 2002</p>
+<p>
+21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
+signature, given in paragraph 1, has two &quot;Throws&quot; paragraphs (3 and
+5).
+</p>
+
+<p>
+In addition, the second &quot;Throws&quot; paragraph (5) includes specification
+(beginning with &quot;Otherwise, the function replaces ...&quot;) that should be
+part of the &quot;Effects&quot; paragraph.
+</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p>
+<b>Section:</b>&nbsp;27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
+<p>
+Is it safe to use standard iostream objects from constructors of
+static objects?  Are standard iostream objects constructed and are
+their associations established at that time?
+</p>
+
+<p>Surpisingly enough, Standard does NOT require that.</p>
+
+<p>
+27.3/2 [lib.iostream.objects] guarantees that standard iostream
+objects are constructed and their associations are established before
+the body of main() begins execution.  It also refers to ios_base::Init
+class as the panacea for constructors of static objects.
+</p>
+
+<p>
+However, there's nothing in 27.3 [lib.iostream.objects],
+in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
+that would require implementations to allow access to standard
+iostream objects from constructors of static objects.
+</p>
+
+<p>Details:</p>
+
+<p>Core text refers to some magic object ios_base::Init, which will
+be discussed below:</p>
+
+<blockquote>
+    &quot;The [standard iostream] objects are constructed, and their
+    associations are established at some time prior to or during
+    first time an object of class basic_ios&lt;charT,traits&gt;::Init
+    is constructed, and in any case before the body of main
+    begins execution.&quot; (27.3/2 [lib.iostream.objects])
+</blockquote>
+
+<p>
+The first <i>non-normative</i> footnote encourages implementations
+to initialize standard iostream objects earlier than required.
+</p>
+
+<p>However, the second <i>non-normative</i> footnote makes an explicit
+and unsupported claim:</p>
+
+<blockquote>
+  &quot;Constructors and destructors for static objects can access these
+  [standard iostream] objects to read input from stdin or write output
+  to stdout or stderr.&quot; (27.3/2 footnote 265 [lib.iostream.objects])
+</blockquote>
+
+<p>
+The only bit of magic is related to that ios_base::Init class.  AFAIK,
+the rationale behind ios_base::Init was to bring an instance of this
+class to each translation unit which #included &lt;iostream&gt; or
+related header.  Such an inclusion would support the claim of footnote
+quoted above, because in order to use some standard iostream object it
+is necessary to #include &lt;iostream&gt;.
+</p>
+
+<p>
+However, while Standard explicitly describes ios_base::Init as
+an appropriate class for doing the trick, I failed to found a
+mention of an _instance_ of ios_base::Init in Standard.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+At the end of header &lt;iostream&gt; synopsis in 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>
+</p>
+
+<pre>
+       namespace std
+       {
+          ... extern istream cin; ...
+</pre>
+
+<p>add the following lines</p>
+
+<pre>
+          namespace
+          {
+             ios_base::Init &lt;some_implementation_defined_name&gt;;
+          }
+        }
+</pre>
+<hr>
+<a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p>
+<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
+<p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
+with the following signature:</p>
+
+<pre>
+  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
+  sb);
+</pre>
+
+<p>is incorrect. It reads</p>
+
+<blockquote>
+  Effects: Calls get(s,n,widen('\n'))
+</blockquote>
+
+<p>which I believe should be:</p>
+
+<blockquote>
+  Effects: Calls get(sb,widen('\n'))
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>Change the <b>Effects</b> paragraph to:</p>
+<blockquote>
+  Effects: Calls get(sb,widen('\n'))
+</blockquote>
+<hr>
+<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p>
+<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
+<p>
+The requirements for multiset and multimap containers (23.1
+[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
+23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
+the stability of the required (mutating) member functions. It appears
+the standard allows these functions to reorder equivalent elements of
+the container at will, yet the pervasive red-black tree implementation
+appears to provide stable behaviour.
+</p>
+
+<p>This is of most concern when considering the behaviour of erase().
+A stability requirement would guarantee the correct working of the
+following 'idiom' that removes elements based on a certain predicate
+function.
+</p>
+
+<pre>
+  multimap&lt;int, int&gt; m;
+  multimap&lt;int, int&gt;::iterator i = m.begin();
+  while (i != m.end()) {
+      if (pred(i))
+          m.erase (i++);
+      else
+          ++i;
+  }
+</pre>
+
+<p>
+Although clause 23.1.2/8 guarantees that i remains a valid iterator
+througout this loop, absence of the stability requirement could
+potentially result in elements being skipped. This would make
+this code incorrect, and, furthermore, means that there is no way
+of erasing these elements without iterating first over the entire
+container, and second over the elements to be erased. This would
+be unfortunate, and have a negative impact on both performance and
+code simplicity.
+</p>
+
+<p>
+If the stability requirement is intended, it should be made explicit
+(probably through an extra paragraph in clause 23.1.2).
+</p>
+<p>
+If it turns out stability cannot be guaranteed, i'd argue that a
+remark or footnote is called for (also somewhere in clause 23.1.2) to
+warn against relying on stable behaviour (as demonstrated by the code
+above).  If most implementations will display stable behaviour, any
+problems emerging on an implementation without stable behaviour will
+be hard to track down by users. This would also make the need for an
+erase_if() member function that much greater.
+</p>
+
+<p>This issue is somewhat related to LWG issue <a href="lwg-closed.html#130">130</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="372"><h3>372.&nbsp;Inconsistent description of stdlib exceptions</h3></a><p>
+<b>Section:</b>&nbsp;17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, &nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Randy Maddox&nbsp; <b>Date:</b>&nbsp;22 Jul 2002</p>
+
+<p>Paragraph 3 under clause 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, Restrictions on
+Exception Handling, states that &quot;Any other functions defined in the
+C++ Standard Library that do not have an exception-specification may
+throw implementation-defined exceptions unless otherwise specified.&quot;
+This statement is followed by a reference to footnote 178 at the
+bottom of that page which states, apparently in reference to the C++
+Standard Library, that &quot;Library implementations are encouraged (but
+not required) to report errors by throwing exceptions from (or derived
+from) the standard exceptions.&quot;</p>
+
+<p>These statements appear to be in direct contradiction to clause
+18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, which states &quot;The class exception defines the
+base class for the types of objects thrown as exceptions by the C++
+Standard library components ...&quot;.</p>
+
+<p>Is this inconsistent?</p>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p>
+<b>Section:</b>&nbsp;27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
+
+<p>
+In 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
+(exception()&amp;badbit) != 0 is used in testing for rethrow, yet
+exception() is the constructor to class std::exception in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
+exceptions() found in 27.4.4 <a href="lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+<hr>
+<a name="374"><h3>374.&nbsp;moneypunct::frac_digits returns int not unsigned</h3></a><p>
+<b>Section:</b>&nbsp;22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;8 Aug 2002</p>
+<p>
+In section 22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, frac_digits() returns type
+&quot;int&quot;. This implies that frac_digits() might return a negative value,
+but a negative value is nonsensical. It should return &quot;unsigned&quot;.
+</p>
+
+<p>
+Similarly, in section 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>, do_frac_digits()
+should return &quot;unsigned&quot;.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p>
+<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
+<p>
+In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
+14 all contain references to &quot;basic_ios::&quot; which should be
+&quot;ios_base::&quot;.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change all references to &quot;basic_ios&quot; in Table 90, Table 91, and
+paragraph 14 to &quot;ios_base&quot;.
+</p>
+<hr>
+<a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p>
+<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
+<p>
+In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
+the four conditions should be mutually exclusive, but they are not.
+The first two cases, as written, are subcases of the third. I think it
+would be clearer if the conditions were rewritten as follows:
+</p>
+
+<blockquote>
+<p>
+  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
+</p>
+
+<p>
+  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
+</p>
+
+<p>
+  (which &amp; (ios_base::in|ios_base::out)) == 
+(ios_base::in|ios_base::out)
+   and way == either ios_base::beg or ios_base::end
+</p>
+
+<p>Otherwise</p>
+</blockquote>
+
+<p>
+As written, it is unclear what should be the result if cases 1 &amp; 2
+are true, but case 3 is false, e.g.,
+</p>
+
+<blockquote>
+  seekoff(0, ios_base::cur, ios_base::in | ios_base::out)
+</blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="377"><h3>377.&nbsp;basic_string::insert and length_error</h3></a><p>
+<b>Section:</b>&nbsp;21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;16 Aug 2002</p>
+<p>
+Section 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, paragraph 4, contains the following,
+&quot;Then throws length_error if size() &gt;= npos - rlen.&quot;
+</p>
+
+<p>
+Related to DR 83, this sentence should probably be removed.
+</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="378"><h3>378.&nbsp;locale immutability and locale::operator=()</h3></a><p>
+<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
+<p>
+I think there is a problem with 22.1.1, p6 which says that
+</p>
+<pre>
+    -6- An instance of locale is immutable; once a facet reference
+        is obtained from it, that reference remains usable as long
+        as the locale value itself exists.
+</pre>
+<p>
+and 22.1.1.2, p4:
+</p>
+<pre>
+    const locale&amp; operator=(const locale&amp; other) throw();
+
+    -4- Effects: Creates a copy of other, replacing the current value.
+</pre>
+<p>
+How can a reference to a facet obtained from a locale object remain
+valid after an assignment that clearly must replace all the facets
+in the locale object? Imagine a program such as this
+</p>
+<pre>
+    std::locale loc (&quot;de_DE&quot;);
+    const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
+    loc = std::locale (&quot;en_US&quot;);
+    const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
+</pre>
+<p>
+Is r0 really supposed to be preserved and destroyed only when loc goes
+out of scope?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Suggest to replace 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, p6 with
+</p>
+<pre>
+    -6- Unless assigned a new value, locale objects are immutable;
+        once a facet reference is obtained from it, that reference
+        remains usable as long as the locale object itself exists
+        or until the locale object is assigned the value of another,
+        distinct locale object.
+</pre>
+<hr>
+<a name="379"><h3>379.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p>
+<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
+<p>
+The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
+</p>
+<pre>
+  charT do_widen (char c) const;
+
+  -11- Effects: Applies the simplest reasonable transformation from
+       a char value or sequence of char values to the corresponding
+       charT value or values. The only characters for which unique
+       transformations are required are those in the basic source
+       character set (2.2). For any named ctype category with a
+       ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
+       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
+</pre>
+<p>
+Shouldn't the last sentence instead read
+</p>
+<pre>
+       For any named ctype category with a ctype&lt;char&gt; facet ctc
+       and valid ctype_base::mask value M
+       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
+</pre>
+<p>
+I.e., if the narrow character c is not a member of a class of
+characters then neither is the widened form of c. (To paraphrase
+footnote 224.)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace the last sentence of 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
+following text:
+</p>
+<pre>
+       For any named ctype category with a ctype&lt;char&gt; facet ctc
+       and valid ctype_base::mask value M
+       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
+</pre>
+<hr>
+<a name="380"><h3>380.&nbsp;typos in codecvt tables 53 and 54</h3></a><p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
+<p>
+Tables 53 and 54 in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled &quot;convert
+result values,&quot; when surely &quot;do_in/do_out result values&quot; must have
+been intended for Table 53 and &quot;do_unshift result values&quot; for Table
+54.
+</p>
+<p>
+Table 54, row 3 says that the meaning of partial is &quot;more characters
+needed to be supplied to complete termination.&quot; The function is not
+supplied any characters, it is given a buffer which it fills with
+characters or, more precisely, destination elements (i.e., an escape
+sequence). So partial means that space for more than (to_limit - to)
+destination elements was needed to terminate a sequence given the
+value of state.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the title of Table 53 to &quot;do_in/do_out result values&quot; and
+the title of Table 54 to &quot;do_unshift result values.&quot;
+</p>
+<p>
+Change the text in Table 54, row 3, under the heading Meaning to
+&quot;space for more than (to_limit - to) destination elements was
+needed to terminate a sequence given the value of state.&quot;
+</p>
+<hr>
+<a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
+<p>
+All but one codecvt member functions that take a state_type argument
+list as one of their preconditions that the state_type argument have
+a valid value. However, according to 22.2.1.5.2, p6,
+codecvt::do_unshift() is the only codecvt member that is supposed to
+return error if the state_type object is invalid.
+</p>
+
+<p>
+It seems to me that the treatment of state_type by all codecvt member
+functions should be the same and the current requirements should be
+changed. Since the detection of invalid state_type values may be
+difficult in general or computationally expensive in some specific
+cases, I propose the following:
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new paragraph before 22.2.1.5.2, p5, and after the function
+declaration below
+</p>
+<pre>
+    result do_unshift(stateT&amp; state,
+    externT* to, externT* to_limit, externT*&amp; to_next) const;
+</pre>
+<p>
+as follows:
+</p>
+<pre>
+    Requires: (to &lt;= to_end) well defined and true; state initialized,
+    if at the beginning of a sequence, or else equal to the result of
+    converting the preceding characters in the sequence.
+</pre>
+<p>
+and change the text in Table 54, row 4, under the heading Meaning
+from
+</p>
+<pre>
+    state has invalid value
+</pre>
+<p>
+to
+</p>
+<pre>
+    an unspecified error has occurred
+</pre>
+<p>
+The return value of error should allow implementers to detect and
+report invalid state values but shouldn't require it, hence the
+word &quot;unspecified&quot; in the new wording.
+</p>
+<hr>
+<a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p>
+<b>Section:</b>&nbsp;22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;30 Aug  2002</p>
+<p>
+It seems that the descriptions of codecvt do_in() and do_out() leave
+sufficient room for interpretation so that two implementations of
+codecvt may not work correctly with the same filebuf. Specifically,
+the following seems less than adequately specified:
+</p>
+
+<ol>
+<li>
+  the conditions under which the functions terminate
+</li>
+<li>
+  precisely when the functions return ok
+</li>
+<li>
+  precisely when the functions return partial
+</li>
+<li>
+  the full set of conditions when the functions return error
+</li>
+</ol>
+
+<ol>
+<li>
+   22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
+   function: ...Stops if it encounters a character it cannot
+   convert...  This assumes that there *is* a character to
+   convert. What happens when there is a sequence that doesn't form a
+   valid source character, such as an unassigned or invalid UNICODE
+   character, or a sequence that cannot possibly form a character
+   (e.g., the sequence &quot;\xc0\xff&quot; in UTF-8)?
+</li>
+<li>
+   Table 53 says that the function returns codecvt_base::ok
+   to indicate that the function(s) &quot;completed the conversion.&quot;
+   Suppose that the source sequence is &quot;\xc0\x80&quot; in UTF-8,
+   with from pointing to '\xc0' and (from_end==from + 1).
+   It is not clear whether the return value should be ok
+   or partial (see below).
+</li>
+<li>
+   Table 53 says that the function returns codecvt_base::partial
+   if &quot;not all source characters converted.&quot; With the from pointers
+   set up the same way as above, it is not clear whether the return
+   value should be partial or ok (see above).
+</li>
+<li>
+   Table 53, in the row describing the meaning of error mistakenly
+   refers to a &quot;from_type&quot; character, without the symbol from_type
+   having been defined. Most likely, the word &quot;source&quot; character
+   is intended, although that is not sufficient. The functions
+   may also fail when they encounter an invalid source sequence
+   that cannot possibly form a valid source character (e.g., as
+   explained in bullet 1 above).
+</li>
+</ol>
+<p>
+Finally, the conditions described at the end of 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
+</p>
+<blockquote>
+    &quot;A return value of partial, if (from_next == from_end),
+    indicates that either the destination sequence has not
+    absorbed all the available destination elements, or that
+    additional source elements are needed before another
+    destination element can be produced.&quot;
+</blockquote>
+<p>
+If the value is partial, it's not clear to me that (from_next
+==from_end) could ever hold if there isn't enough room
+in the destination buffer. In order for (from_next==from_end) to
+hold, all characters in that range must have been successfully
+converted (according to 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
+further source characters to convert, no more room in the
+destination buffer can be needed.
+</p>
+<p>
+It's also not clear to me that (from_next==from_end) could ever
+hold if additional source elements are needed to produce another
+destination character (not element as incorrectly stated in the
+text). partial is returned if &quot;not all source characters have
+been converted&quot; according to Table 53, which also implies that
+(from_next==from) does NOT hold.
+</p>
+<p>
+Could it be that the intended qualifying condition was actually
+(from_next != from_end), i.e., that the sentence was supposed
+to read
+</p>
+<blockquote>
+    &quot;A return value of partial, if (from_next != from_end),...&quot;
+</blockquote>
+<p>
+which would make perfect sense, since, as far as I understand it,
+partial can only occur if (from_next != from_end)?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+To address these issues, I propose that paragraphs 2, 3, and 4
+be rewritten as follows. The proposal incorporates the accepted
+resolution of lwg issue 19.
+</p>
+<pre>
+-2- Effects: Converts characters in the range of source elements
+    [from, from_end), placing the results in sequential positions
+    starting at destination to. Converts no more than (from_end&shy;from)
+    source elements, and stores no more than (to_limit&shy;to)
+    destination elements.
+
+    Stops if it encounters a sequence of source elements it cannot
+    convert to a valid destination character. It always leaves the
+    from_next and to_next pointers pointing one beyond the last
+    element successfully converted.
+
+    [Note: If returns noconv, internT and externT are the same type
+    and the converted sequence is identical to the input sequence
+    [from, from_next). to_next is set equal to to, the value of
+    state is unchanged, and there are no changes to the values in
+    [to, to_limit). --end note]
+
+-3- Notes: Its operations on state are unspecified.
+    [Note: This argument can be used, for example, to maintain shift
+    state, to specify conversion options (such as count only), or to
+    identify a cache of seek offsets. --end note]
+
+-4- Returns: An enumeration value, as summarized in Table 53:
+
+    Table 53 -- do_in/do_out result values
+
+     Value      Meaning
+    +---------+----------------------------------------------------+
+    | ok      | successfully completed the conversion of all       |
+    |         | complete characters in the source range            |
+    +---------+----------------------------------------------------+
+    | partial | the characters in the source range would, after    |
+    |         | conversion, require space greater than that        |
+    |         | available in the destination range                 |
+    +---------+----------------------------------------------------+
+    | error   | encountered either a sequence of elements in the   |
+    |         | source range forming a valid source character that |
+    |         | could not be converted to a destination character, |
+    |         | or a sequence of elements in the source range that |
+    |         | could not possibly form a valid source character   |
+    +---------+----------------------------------------------------+
+    | noconv  | internT and externT are the same type, and input   |
+    |         | sequence is identical to converted sequence        |
+    +---------+----------------------------------------------------+
+
+    A return value of partial, i.e., if (from_next != from_end),
+    indicates that either the destination sequence has not absorbed
+    all the available destination elements, or that additional
+    source elements are needed before another destination character
+    can be produced.
+</pre>
 <p>----- End of document -----</p>
 </body>
 </html>
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html
index eea548b8db7c..41ae2f822c65 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -5,11 +5,11 @@
 <table>
 <tr>
 <td align="left">Doc. no.</td>
-<td align="left">J16/02-0028 = WG21 N1370</td>
+<td align="left">J16/02-0049 = WG21 N1391</td>
 </tr>
 <tr>
 <td align="left">Date:</td>
-<td align="left">10 May 2002</td>
+<td align="left">10 Sep 2002</td>
 </tr>
 <tr>
 <td align="left">Project:</td>
@@ -17,10 +17,10 @@
 </tr>
 <tr>
 <td align="left">Reply to:</td>
-<td align="left">Matt Austern &lt;austern@research.att.com&gt;</td>
+<td align="left">Matt Austern &lt;austern@apple.com&gt;</td>
 </tr>
 </table>
-<h1>C++ Standard Library Defect Report List (Revision 22)</h1>
+<h1>C++ Standard Library Defect Report List (Revision 23)</h1>
   <p>Reference ISO/IEC IS 14882:1998(E)</p>
   <p>Also see:</p>
     <ul>
@@ -42,6 +42,10 @@
   document.</p>
 <h2>Revision History</h2>
 <ul>
+<li>R23: 
+Pre-Santa Cruz mailing.  Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
+Moved issues in the TC to TC status.
+</li>
 <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>
@@ -204,7 +208,7 @@ format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
 <h2>Defect Reports</h2>
 <hr>
 <a name="1"><h3>1.&nbsp;C library linkage editing oversight</h3></a><p>
-<b>Section:</b>&nbsp;17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</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;16 Nov 1997</p>
+<b>Section:</b>&nbsp;17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;16 Nov 1997</p>
 <p>The change specified in the proposed resolution below did not make
 it into the Standard. This change was accepted in principle at the
 London meeting, and the exact wording below was accepted at the
@@ -229,7 +233,7 @@ from:</p>
 </blockquote>
 <hr>
 <a name="3"><h3>3.&nbsp;Atexit registration during atexit() call is not described</h3></a><p>
-<b>Section:</b>&nbsp;18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</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;12 Dec 1997</p>
+<b>Section:</b>&nbsp;18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;12 Dec 1997</p>
 <p>We appear not to have covered all the possibilities of
  exit processing with respect to
 atexit registration. <br>
@@ -349,7 +353,7 @@ committee decides. </p>
 supporting to the proposed resolution.</p>
 <hr>
 <a name="5"><h3>5.&nbsp;String::compare specification questionable</h3></a><p>
-<b>Section:</b>&nbsp;21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;11 Dec 1997</p>
+<b>Section:</b>&nbsp;21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;11 Dec 1997</p>
 <p>At the very end of the basic_string class definition is the signature: int
 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 following text this is defined as: returns
@@ -432,7 +436,7 @@ the Standard which must be fixed.&nbsp; The same problem was also
 identified in issues 7 (item 5) and 87.</p>
 <hr>
 <a name="7"><h3>7.&nbsp;String clause minor problems</h3></a><p>
-<b>Section:</b>&nbsp;21 <a href="lib-strings.html#lib.strings"> [lib.strings]</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;15 Dec 1997</p>
+<b>Section:</b>&nbsp;21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Dec 1997</p>
 <p>(1) In 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 InputIterator) makes no sense. It refers to a member function that
@@ -503,7 +507,7 @@ with:<br>
 s+n) overlap.&quot;</p>
 <hr>
 <a name="8"><h3>8.&nbsp;Locale::global lacks guarantee</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</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;24 Dec 1997</p>
+<b>Section:</b>&nbsp;22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Dec 1997</p>
 <p>It appears there's an important guarantee missing from clause
 22. We're told that invoking locale::global(L) sets the C locale if L
 has a name. However, we're not told whether or not invoking
@@ -522,7 +526,7 @@ paragraph 2:&nbsp; </p>
 </blockquote>
 <hr>
 <a name="9"><h3>9.&nbsp;Operator new(0) calls should not yield the same pointer</h3></a><p>
-<b>Section:</b>&nbsp;18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</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;4 Jan 1998</p>
+<b>Section:</b>&nbsp;18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;4 Jan 1998</p>
 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 calls to operator new(0) yield the same pointer, an implementation
@@ -577,7 +581,7 @@ list maintainer's note: the IS is the same.]</p>
 supporting to the proposed resolution.</p>
 <hr>
 <a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p>
-<b>Section:</b>&nbsp;23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</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;22 Jan 1998</p>
+<b>Section:</b>&nbsp;23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 not documented in 23.3.5.2. </p>
 
@@ -625,7 +629,7 @@ input&quot; implies the desired semantics. See 27.6.1.2 <a href="lib-iostreams.h
 </p>
 <hr>
 <a name="13"><h3>13.&nbsp;Eos refuses to die</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;William M. Miller&nbsp; <b>Date:</b>&nbsp;3 Mar 1998</p>
+<b>Section:</b>&nbsp;27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;William M. Miller&nbsp; <b>Date:</b>&nbsp;3 Mar 1998</p>
 <p>In 27.6.1.2.3, there is a reference to &quot;eos&quot;, which is
 the only one in the whole draft (at least using Acrobat search), so
 it's undefined. </p>
@@ -634,7 +638,7 @@ it's undefined. </p>
 &quot;charT()&quot;</p>
 <hr>
 <a name="14"><h3>14.&nbsp;Locale::combine should be const</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>locale::combine is the only member function of locale (other than constructors and
 destructor) that is not const. There is no reason for it not to be const, and good reasons
 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
@@ -653,7 +657,7 @@ time, but the omission was not noticed. </p>
 </blockquote>
 <hr>
 <a name="15"><h3>15.&nbsp;Locale::name requirement inconsistent</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>locale::name() is described as returning a string that can be passed to a locale
 constructor, but there is no matching constructor. </p>
 <p><b>Proposed resolution:</b></p>
@@ -663,7 +667,7 @@ constructor, but there is no matching constructor. </p>
 </p>
 <hr>
 <a name="16"><h3>16.&nbsp;Bad ctype_byname&lt;char&gt; decl</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 lists. </p>
@@ -673,7 +677,7 @@ lists. </p>
 from 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
 <hr>
 <a name="17"><h3>17.&nbsp;Bad bool parsing</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;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>This section describes the process of parsing a text boolean value from the input
 stream. It does not say it recognizes either of the sequences &quot;true&quot; or
 &quot;false&quot; and returns the corresponding bool value; instead, it says it recognizes
@@ -753,7 +757,7 @@ change &quot;&amp;&amp;&quot; to &quot;&amp;&quot;.</p>
 </blockquote>
 <hr>
 <a name="18"><h3>18.&nbsp;Get(...bool&amp;) omitted</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;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 that parses bool values was omitted from the list of definitions of non-virtual
 members, though it is listed in the class definition and the corresponding
@@ -764,7 +768,7 @@ another get member for bool&amp;, copied from the entry in
 22.2.2.1 <a href="lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
 <hr>
 <a name="19"><h3>19.&nbsp;&quot;Noconv&quot; definition too vague</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>
 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 specified to return noconv if &quot;no conversion is
@@ -790,7 +794,7 @@ Change the entry for noconv in the table under paragraph 4 in section
 </blockquote>
 <hr>
 <a name="20"><h3>20.&nbsp;Thousands_sep returns wrong type</h3></a><p>
-<b>Section:</b>&nbsp;22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 that it returns a value of type char_type. Here it is erroneously
@@ -800,7 +804,7 @@ described as returning a &quot;string_type&quot;. </p>
 &quot;string_type&quot; to &quot;char_type&quot;. </p>
 <hr>
 <a name="21"><h3>21.&nbsp;Codecvt_byname&lt;&gt; instantiations</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;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the second table in the section, captioned &quot;Required
 instantiations&quot;, the instantiations for codecvt_byname&lt;&gt;
 have been omitted. These are necessary to allow users to construct a
@@ -816,7 +820,7 @@ codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 </blockquote>
 <hr>
 <a name="22"><h3>22.&nbsp;Member open vs. flags</h3></a><p>
-<b>Section:</b>&nbsp;27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 responds to or changes flags in the error status for the stream. A strict reading
 indicates that it ignores the bits and does not change them, which confuses users who do
@@ -843,7 +847,7 @@ believes to have been the original intent.</p>
 
 <hr>
 <a name="24"><h3>24.&nbsp;&quot;do_convert&quot; doesn't exist</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 symbol &quot;do_convert&quot; which is not defined in the
 standard. This is a leftover from an edit, and should be &quot;do_in
@@ -854,7 +858,7 @@ and do_out&quot;. </p>
 or do_out&quot;. </p>
 <hr>
 <a name="25"><h3>25.&nbsp;String operator&lt;&lt; uses width() value wrong</h3></a><p>
-<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 the smaller of os.width() and str.size(), to pad &quot;as described in stage 3&quot;
 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
@@ -870,7 +874,7 @@ to: <br>
 ...&quot;</p>
 <hr>
 <a name="26"><h3>26.&nbsp;Bad sentry example</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In paragraph 6, the code in the example: </p>
 
 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
@@ -905,7 +909,7 @@ decided that it would be counter-productive to include such a lengthy
 example, which might well still contain errors.</p>
 <hr>
 <a name="27"><h3>27.&nbsp;String::erase(range) yields wrong iterator</h3></a><p>
-<b>Section:</b>&nbsp;21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The string::erase(iterator first, iterator last) is specified to return an element one
 place beyond the next element after the last one erased. E.g. for the string
 &quot;abcde&quot;, erasing the range ['b'..'d') would yield an iterator for element 'e',
@@ -926,7 +930,7 @@ while 'd' has not been erased. </p>
 </blockquote>
 <hr>
 <a name="28"><h3>28.&nbsp;Ctype&lt;char&gt;is ambiguous</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
 something very different from what was intended. Paragraph 4 says </p>
 
@@ -946,7 +950,7 @@ vec[]. </p>
 </blockquote>
 <hr>
 <a name="29"><h3>29.&nbsp;Ios_base::init doesn't exist</h3></a><p>
-<b>Section:</b>&nbsp;27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>Sections 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
 a function ios_base::init, which is not defined. Probably they mean
 basic_ios&lt;&gt;::init, defined in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
@@ -974,7 +978,7 @@ should read </p>
 </blockquote>
 <hr>
 <a name="30"><h3>30.&nbsp;Wrong header for LC_*</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;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
 <p><b>Proposed resolution:</b></p>
@@ -982,7 +986,7 @@ where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
 &quot;&lt;cctype&gt;&quot; to read &quot;&lt;clocale&gt;&quot;. </p>
 <hr>
 <a name="31"><h3>31.&nbsp;Immutable locale values</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>Paragraph 6, says &quot;An instance of <tt>locale</tt> is
 <i>immutable</i>; once a facet reference is obtained from it,
 ...&quot;. This has caused some confusion, because locale variables
@@ -1006,7 +1010,7 @@ are manifestly assignable. </p>
 </blockquote>
 <hr>
 <a name="32"><h3>32.&nbsp;Pbackfail description inconsistent</h3></a><p>
-<b>Section:</b>&nbsp;27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The description of the required state before calling virtual member
 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
@@ -1037,7 +1041,7 @@ Specifically, the latter says it calls pbackfail if: </p>
 the argument value.</p>
 <hr>
 <a name="33"><h3>33.&nbsp;Codecvt&lt;&gt; mentions from_type</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the table defining the results from do_out and do_in, the specification for the
 result <i>error</i> says </p>
 
@@ -1056,7 +1060,7 @@ in the table for the case of _error_ with </p>
 </blockquote>
 <hr>
 <a name="34"><h3>34.&nbsp;True/falsename() not in ctype&lt;&gt;</h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
 22.2.2.1.2, addressed in (4). </p>
@@ -1071,7 +1075,7 @@ string_type s = val ? np.truename() : np.falsename(); </pre>
 </blockquote>
 <hr>
 <a name="35"><h3>35.&nbsp;No manipulator unitbuf in synopsis</h3></a><p>
-<b>Section:</b>&nbsp;27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In 27.4.5.1 <a href="lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
 named &quot;unitbuf&quot;. Unlike other manipulators, it's not listed
 in synopsis. Similarly for &quot;nounitbuf&quot;. </p>
@@ -1085,7 +1089,7 @@ ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
 </blockquote>
 <hr>
 <a name="36"><h3>36.&nbsp;Iword &amp; pword storage lifetime omitted</h3></a><p>
-<b>Section:</b>&nbsp;27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
 specified badly, so that an implementation which only keeps the last value stored appears
 to conform. In particular, it says: </p>
@@ -1115,7 +1119,7 @@ paragraph 4, replace the sentence: </p>
 <p>substituting &quot;iword&quot; or &quot;pword&quot; as appropriate. </p>
 <hr>
 <a name="37"><h3>37.&nbsp;Leftover &quot;global&quot; reference</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
 
 <blockquote>
@@ -1134,7 +1138,7 @@ expression </p>
 </blockquote>
 <hr>
 <a name="38"><h3>38.&nbsp;Facet definition incomplete</h3></a><p>
-<b>Section:</b>&nbsp;22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>It has been noticed by Esa Pulkkinen that the definition of
 &quot;facet&quot; is incomplete. In particular, a class derived from
 another facet, but which does not define a member <i>id</i>, cannot
@@ -1165,7 +1169,7 @@ contains (not inherits) the public static member
 
 <hr>
 <a name="39"><h3>39.&nbsp;istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3></a><p>
-<b>Section:</b>&nbsp;24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
 3, the standard contains three lines of garbage text left over from a previous edit. </p>
 
@@ -1175,11 +1179,11 @@ sbuf_-&gt;sbumpc();
 return(tmp); </pre>
 </blockquote>
 <p><b>Proposed resolution:</b></p>
-<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
+<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
 end of paragraph 3. </p>
 <hr>
 <a name="40"><h3>40.&nbsp;Meaningless normative paragraph in examples</h3></a><p>
-<b>Section:</b>&nbsp;22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>Paragraph 3 of the locale examples is a description of part of an
 implementation technique that has lost its referent, and doesn't mean
 anything. </p>
@@ -1190,7 +1194,7 @@ editor's option) replace it with a place-holder to keep the paragraph
 numbering the same. </p>
 <hr>
 <a name="41"><h3>41.&nbsp;Ios_base needs clear(), exceptions()</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;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they &quot;set badbit,
 which may throw an exception&quot;. However, ios_base offers no
 interface to set or to test badbit; those interfaces are defined in
@@ -1217,7 +1221,7 @@ setstate(badbit).]</i></p>
 
 <hr>
 <a name="42"><h3>42.&nbsp;String ctors specify wrong default allocator</h3></a><p>
-<b>Section:</b>&nbsp;21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
+<b>Section:</b>&nbsp;21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The basic_string&lt;&gt; copy constructor: </p>
 
 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
@@ -1291,7 +1295,7 @@ reflects the LWG consensus.
 ]</i></p>
 <hr>
 <a name="46"><h3>46.&nbsp;Minor Annex D errors</h3></a><p>
-<b>Section:</b>&nbsp;D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Brendan Kehoe&nbsp; <b>Date:</b>&nbsp; 1 Jun 1998</p>
+<b>Section:</b>&nbsp;D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Brendan Kehoe&nbsp; <b>Date:</b>&nbsp; 1 Jun 1998</p>
 <p>See lib-6522 and edit-814.</p>
 <p><b>Proposed resolution:</b></p>
 <p>Change D.7.1 <a href="future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
@@ -1316,7 +1320,7 @@ int_type:</p>
          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
 <hr>
 <a name="47"><h3>47.&nbsp;Imbue() and getloc() Returns clauses swapped</h3></a><p>
-<b>Section:</b>&nbsp;27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</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;21 Jun 1998</p>
+<b>Section:</b>&nbsp;27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
 section has two RETURNS clauses, and they make no sense as
 stated. They make perfect sense, though, if you swap them. Am I
@@ -1326,7 +1330,7 @@ accident?</p>
 <p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
 <hr>
 <a name="48"><h3>48.&nbsp;Use of non-existent exception constructor</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;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
 base class, exception, with exception(msg). Class exception (see
 18.6.1) has no such constructor.</p>
@@ -1421,7 +1425,7 @@ text was added in the non-normative footnote to say that operations
 on the two streams can be mixed arbitrarily.]</i></p>
 <hr>
 <a name="50"><h3>50.&nbsp;Copy constructor and assignment operator of ios_base</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;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
 <p>As written, ios_base has a copy constructor and an assignment
 operator. (Nothing in the standard says it doesn't have one, and all
 classes have copy constructors and assignment operators unless you
@@ -1448,7 +1452,7 @@ constructor and operator= members as being private.</p>
 outweighs any benefit of allowing ios_base objects to be copyable.</p>
 <hr>
 <a name="51"><h3>51.&nbsp;Requirement to not invalidate iterators missing</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;David Vandevoorde&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
+<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;David Vandevoorde&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
 <p>The std::sort algorithm can in general only sort a given sequence
 by moving around values. The list&lt;&gt;::sort() member on the other
 hand could move around values or just update internal pointers. Either
@@ -1495,7 +1499,7 @@ particularly the addition of the phrase &quot;or change the values
 of&quot;</p>
 <hr>
 <a name="52"><h3>52.&nbsp;Small I/O problems</h3></a><p>
-<b>Section:</b>&nbsp;27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</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;23 Jun 1998</p>
+<b>Section:</b>&nbsp;27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
 <p>First, 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
 it should be titled &quot;basic_ios&lt;&gt;() effects&quot;, not
 &quot;ios_base() effects&quot;. </p>
@@ -1523,7 +1527,7 @@ arithmetic is possible.) </p>
 effects&quot;. </p>
 <hr>
 <a name="53"><h3>53.&nbsp;Basic_ios destructor unspecified</h3></a><p>
-<b>Section:</b>&nbsp;27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</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;23 Jun 1998</p>
+<b>Section:</b>&nbsp;27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
 The important question is whether basic_ios::~basic_ios() destroys
 rdbuf().</p>
@@ -1544,7 +1548,7 @@ footnote which incorrectly said &quot;<tt>rdbuf(0)</tt> does not set
 <tt>badbit</tt>&quot;.</p>
 <hr>
 <a name="54"><h3>54.&nbsp;Basic_streambuf's destructor</h3></a><p>
-<b>Section:</b>&nbsp;27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</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 Jun 1998</p>
+<b>Section:</b>&nbsp;27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Jun 1998</p>
 <p>The class synopsis for basic_streambuf shows a (virtual)
 destructor, but the standard doesn't say what that destructor does. My
 assumption is that it does nothing, but the standard should say so
@@ -1559,7 +1563,7 @@ explicitly. </p>
 </blockquote>
 <hr>
 <a name="55"><h3>55.&nbsp;Invalid stream position is undefined</h3></a><p>
-<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;26 Jun 1998</p>
+<b>Section:</b>&nbsp;27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;26 Jun 1998</p>
 <p>Several member functions in clause 27 are defined in certain
 circumstances to return an &quot;invalid stream position&quot;, a term
 that is defined nowhere in the standard. Two places (27.5.2.4.2,
@@ -1618,7 +1622,7 @@ stores an invalid stream position&quot; to &quot;the return value is
 <tt>pos_type(off_type(-1))</tt>&quot;</p>
 <hr>
 <a name="56"><h3>56.&nbsp;Showmanyc's return type</h3></a><p>
-<b>Section:</b>&nbsp;27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</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;29 Jun 1998</p>
+<b>Section:</b>&nbsp;27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;29 Jun 1998</p>
 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
 showmanyc has return type int. However, 27.5.2.4.3 says that its
 return type is streamsize. </p>
@@ -1627,7 +1631,7 @@ return type is streamsize. </p>
 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
 <hr>
 <a name="57"><h3>57.&nbsp;Mistake in char_traits</h3></a><p>
-<b>Section:</b>&nbsp;21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</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;1 Jul 1998</p>
+<b>Section:</b>&nbsp;21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;1 Jul 1998</p>
 <p>21.1.3.2, paragraph 3, says &quot;The types streampos and
 wstreampos may be different if the implementation supports no shift
 encoding in narrow-oriented iostreams but supports one or more shift
@@ -1646,7 +1650,7 @@ begins &quot;The types streampos and wstreampos may be
 different...&quot; . </p>
 <hr>
 <a name="59"><h3>59.&nbsp;Ambiguity in specification of gbump</h3></a><p>
-<b>Section:</b>&nbsp;27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</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;28 Jul 1998</p>
+<b>Section:</b>&nbsp;27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;28 Jul 1998</p>
 <p>27.5.2.3.1 says that basic_streambuf::gbump() &quot;Advances the
 next pointer for the input sequence by n.&quot; </p>
 
@@ -1675,7 +1679,7 @@ former interpretation.)</p>
 effects.</p>
 <hr>
 <a name="60"><h3>60.&nbsp;What is a formatted input function?</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</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;3 Aug 1998</p>
+<b>Section:</b>&nbsp;27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Aug 1998</p>
 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
 formatted input functions. Some of the functions defined in section
 27.6.1.2 explicitly say that those requirements apply (&quot;Behaves
@@ -1972,7 +1976,7 @@ by Judy Ward and Matt Austern.  This proposed resolution is section
 VI of that paper.</p>
 <hr>
 <a name="61"><h3>61.&nbsp;Ambiguity in iostreams exception policy</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</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;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The introduction to the section on unformatted input (27.6.1.3)
 says that every unformatted input function catches all exceptions that
 were thrown during input, sets badbit, and then conditionally rethrows
@@ -2008,7 +2012,7 @@ parenthetical comment: &quot;(Exceptions thrown from
 resolution as better standardese.</p>
 <hr>
 <a name="62"><h3>62.&nbsp;<tt>Sync</tt>'s return value</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</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;6 Aug 1998</p>
+<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
 &quot;calls rdbuf()-&gt;pubsync() and, if that function returns -1
 ... returns traits::eof().&quot; </p>
@@ -2021,7 +2025,7 @@ traits::int_type while the return type of sync() is int. </p>
 </p>
 <hr>
 <a name="63"><h3>63.&nbsp;Exception-handling policy for unformatted output</h3></a><p>
-<b>Section:</b>&nbsp;27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</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;11 Aug 1998</p>
+<b>Section:</b>&nbsp;27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998</p>
 <p>Clause 27 details an exception-handling policy for formatted input,
 unformatted input, and formatted output. It says nothing for
 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
@@ -2052,7 +2056,7 @@ input, unformatted input, and formatted output.
 <hr>
 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</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;11 Aug 1998 </p>
+<b>Section:</b>&nbsp;27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998 </p>
 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
 different ways, depending on whether the second sentence is read as an
 elaboration of the first. </p>
@@ -2070,7 +2074,7 @@ elaboration of the first. </p>
 </blockquote>
 <hr>
 <a name="66"><h3>66.&nbsp;Strstreambuf::setbuf</h3></a><p>
-<b>Section:</b>&nbsp;D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</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 Aug 1998</p>
+<b>Section:</b>&nbsp;D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Aug 1998</p>
 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
 &quot;Performs an operation that is defined separately for each class
 derived from strstreambuf&quot;. This is obviously an incorrect
@@ -2089,7 +2093,7 @@ with:</p>
 </blockquote>
 <hr>
 <a name="68"><h3>68.&nbsp;Extractors for char* should store null at end</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</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;14 Jul 1998</p>
+<b>Section:</b>&nbsp;27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;14 Jul 1998</p>
 <p>Extractors for char* (27.6.1.2.3) do not store a null character
 after the extracted character sequence whereas the unformatted
 functions like get() do. Why is this?</p>
@@ -2116,7 +2120,7 @@ item from:</p>
 </blockquote>
 <hr>
 <a name="69"><h3>69.&nbsp;Must elements of a vector be contiguous?</h3></a><p>
-<b>Section:</b>&nbsp;23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
+<b>Section:</b>&nbsp;23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
 
 <p>(Please note that this is entirely separate from the question of
@@ -2150,7 +2154,7 @@ directly defined in the standard.  Discussion included:</p>
 </ul>
 <hr>
 <a name="70"><h3>70.&nbsp;Uncaught_exception() missing throw() specification</h3></a><p>
-<b>Section:</b>&nbsp;18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</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;Unknown</p>
+<b>Section:</b>&nbsp;18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;Unknown</p>
 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
 
 <p>uncaught_exception() doesn't have a throw specification.</p>
@@ -2164,7 +2168,7 @@ exception safety is very important.</p>
 <p>In 15.5.3 <a href="except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add &quot;throw()&quot; to uncaught_exception().</p>
 <hr>
 <a name="71"><h3>71.&nbsp;Do_get_monthname synopsis missing argument</h3></a><p>
-<b>Section:</b>&nbsp;22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;13 Aug 1998</p>
+<b>Section:</b>&nbsp;22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;13 Aug 1998</p>
 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
 is described in 22.2.5.1.2 <a href="lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
 consistent with do_get_weekday and with its specified use by member
@@ -2180,7 +2184,7 @@ the declaration of member do_monthname as follows:</p>
 <hr>
 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;8 Sep 1998</p>
+<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;8 Sep 1998</p>
 <p>The text of <tt>codecvt::do_max_length</tt>'s &quot;Returns&quot;
 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
 parentheses and a spurious <b>n</b>.</p>
@@ -2197,7 +2201,7 @@ following:</p>
 </blockquote>
 <hr>
 <a name="75"><h3>75.&nbsp;Contradiction in <tt>codecvt::length</tt>'s argument types</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
+<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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp; Matt
 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
@@ -2349,14 +2353,14 @@ return value.]</i></p>
   </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>
+<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#TC">TC</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>
 <p><b>Proposed resolution:</b></p>
 <p>In the 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
 &quot;event_call_back&quot; to &quot;event_callback&quot;. </p>
 <hr>
 <a name="79"><h3>79.&nbsp;Inconsistent declaration of polar()</h3></a><p>
-<b>Section:</b>&nbsp;26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</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>
+<b>Section:</b>&nbsp;26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
 
@@ -2372,14 +2376,14 @@ return value.]</i></p>
 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
 <hr>
 <a name="80"><h3>80.&nbsp;Global Operators of complex declared twice</h3></a><p>
-<b>Section:</b>&nbsp;26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</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>
+<b>Section:</b>&nbsp;26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
 class complex. This redundancy should be removed.</p>
 <p><b>Proposed resolution:</b></p>
 <p>Reduce redundancy according to the general style of the standard. </p>
 <hr>
 <a name="83"><h3>83.&nbsp;String::npos vs. string::max_size()</h3></a><p>
-<b>Section:</b>&nbsp;21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</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>
+<b>Section:</b>&nbsp;21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>Many string member functions throw if size is getting or exceeding
 npos. However, I wonder why they don't throw if size is getting or
 exceeding max_size() instead of npos.  May be npos is known at compile
@@ -2399,7 +2403,7 @@ described in this clause...&quot;) add a new paragraph:</p>
 <p>The LWG believes length_error is the correct exception to throw.</p>
 <hr>
 <a name="86"><h3>86.&nbsp;String constructors don't describe exceptions</h3></a><p>
-<b>Section:</b>&nbsp;21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</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>
+<b>Section:</b>&nbsp;21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>The constructor from a range:</p>
 
 <pre>template&lt;class InputIterator&gt; 
@@ -2419,7 +2423,7 @@ because they are subsumed by the general wording added by the
 resolution for issue <a href="lwg-defects.html#83">83</a>.</p>
 <hr>
 <a name="90"><h3>90.&nbsp;Incorrect description of operator &gt;&gt; for strings</h3></a><p>
-<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
+<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
 
 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
@@ -2553,7 +2557,7 @@ conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
 <hr>
 <a name="106"><h3>106.&nbsp;Numeric library private members are implementation defined</h3></a><p>
-<b>Section:</b>&nbsp;26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
+<b>Section:</b>&nbsp;26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 <p>This is the only place in the whole standard where the implementation has to document
 something private.</p>
 <p><b>Proposed resolution:</b></p>
@@ -2573,7 +2577,7 @@ Remove the comment which says &quot;// remainder implementation defined&quot; fr
 </ul>
 <hr>
 <a name="108"><h3>108.&nbsp;Lifetime of exception::what() return unspecified</h3></a><p>
-<b>Section:</b>&nbsp;18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
+<b>Section:</b>&nbsp;18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
 exception::what() is left unspecified. This issue has implications
 with exception safety of exception handling: some exceptions should
@@ -2701,7 +2705,7 @@ Leave open - 1.]</i></p>
 
 <hr>
 <a name="110"><h3>110.&nbsp;istreambuf_iterator::equal not const</h3></a><p>
-<b>Section:</b>&nbsp;24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;15 Oct 1998</p>
+<b>Section:</b>&nbsp;24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;15 Oct 1998</p>
 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
 &quot;const&quot;, yet 24.5.3.6 <a href="lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
 which is const, calls it. This is contradictory. </p>
@@ -2720,7 +2724,7 @@ replace:</p>
 </blockquote>
 <hr>
 <a name="112"><h3>112.&nbsp;Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p>
-<b>Section:</b>&nbsp;24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</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;20 Oct 1998</p>
+<b>Section:</b>&nbsp;24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
 reads &quot;<i>s</i> is not null&quot;. However, <i>s</i> is a
@@ -2740,7 +2744,7 @@ reading:</p>
 </blockquote>
 <hr>
 <a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p>
-<b>Section:</b>&nbsp;18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</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;28 Oct 1998</p>
+<b>Section:</b>&nbsp;18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
 <p>Section 18.4.1.3 contains the following example: </p>
 
 <pre>[Example: This can be useful for constructing an object at a known address:
@@ -2766,7 +2770,7 @@ likely to fail.</p>
 </blockquote>
 <hr>
 <a name="115"><h3>115.&nbsp;Typo in strstream constructors</h3></a><p>
-<b>Section:</b>&nbsp;D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</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;2 Nov 1998</p>
+<b>Section:</b>&nbsp;D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;2 Nov 1998</p>
 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
 
 <blockquote>
@@ -2958,7 +2962,7 @@ operator&gt;&gt;(int&amp; val);</pre>
 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
 <hr>
 <a name="119"><h3>119.&nbsp;Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
-<b>Section:</b>&nbsp;17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
+<b>Section:</b>&nbsp;17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 <p>Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
 
 <p>&quot;An implementation may strengthen the exception-specification
@@ -2992,7 +2996,7 @@ exception-specification for a function&quot;</p>
 exception-specification for a non-virtual function&quot;. </p>
 <hr>
 <a name="122"><h3>122.&nbsp;streambuf/wstreambuf description should not say they are specializations</h3></a><p>
-<b>Section:</b>&nbsp;27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
+<b>Section:</b>&nbsp;27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 <p>Section 27.5.2 describes the streambuf classes this way: </p>
 
 <blockquote>
@@ -3016,7 +3020,7 @@ sentences). </p>
 typedefs and that is sufficient. </p>
 <hr>
 <a name="124"><h3>124.&nbsp;ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
+<b>Section:</b>&nbsp;22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 <p>In Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
 to return a const char* not a const charT*. </p>
@@ -3026,7 +3030,7 @@ to return a const char* not a const charT*. </p>
 charT*</tt>. </p>
 <hr>
 <a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</h3></a><p>
-<b>Section:</b>&nbsp;26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
+<b>Section:</b>&nbsp;26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 <p>In Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is
 declared to return a valarray&lt;T&gt;, but in Section 26.3.2.5 <a href="lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The
 latter appears to be correct. </p>
@@ -3036,7 +3040,7 @@ latter appears to be correct. </p>
 <tt>valarray&lt;bool&gt;</tt>. </p>
 <hr>
 <a name="126"><h3>126.&nbsp;typos in Effects clause of ctype::do_narrow()</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
+<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
 <p><b>Proposed resolution:</b></p>
 <p>In Section 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
@@ -3056,7 +3060,7 @@ latter appears to be correct. </p>
 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
 <hr>
 <a name="127"><h3>127.&nbsp;auto_ptr&lt;&gt; conversion issues</h3></a><p>
-<b>Section:</b>&nbsp;20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Colvin&nbsp; <b>Date:</b>&nbsp;17 Feb 1999</p>
+<b>Section:</b>&nbsp;20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Colvin&nbsp; <b>Date:</b>&nbsp;17 Feb 1999</p>
 <p>There are two problems with the current <tt>auto_ptr</tt> wording
 in the standard: </p>
 
@@ -3122,7 +3126,7 @@ a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
 </blockquote>
 <hr>
 <a name="129"><h3>129.&nbsp;Need error indication from seekp() and seekg()</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</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;22 Feb 1999</p>
+<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;22 Feb 1999</p>
 <p>Currently, the standard does not specify how seekg() and seekp()
 indicate failure. They are not required to set failbit, and they can't
 return an error indication because they must return *this, i.e. the
@@ -3146,7 +3150,7 @@ stream state in case of failure.</p>
 <p>Setting failbit is the usual error reporting mechanism for streams</p>
 <hr>
 <a name="132"><h3>132.&nbsp;list::resize description uses random access iterators</h3></a><p>
-<b>Section:</b>&nbsp;23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
+<b>Section:</b>&nbsp;23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
 <p>The description reads:</p>
 
 <p>-1- Effects:</p>
@@ -3178,7 +3182,7 @@ with David Abrahams. They had a discussion and believe there is
 no issue of exception safety with the proposed resolution.]</i></p>
 <hr>
 <a name="133"><h3>133.&nbsp;map missing get_allocator()</h3></a><p>
-<b>Section:</b>&nbsp;23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
+<b>Section:</b>&nbsp;23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
 <p>The title says it all.</p>
 <p><b>Proposed resolution:</b></p>
 <p>Insert in 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
@@ -3187,7 +3191,7 @@ after operator= in the map declaration:</p>
 <pre>    allocator_type get_allocator() const;</pre>
 <hr>
 <a name="134"><h3>134.&nbsp;vector constructors over specified</h3></a><p>
-<b>Section:</b>&nbsp;23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
+<b>Section:</b>&nbsp;23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
 <p>The complexity description says: &quot;It does at most 2N calls to the copy constructor
 of T and logN reallocations if they are just input iterators ...&quot;.</p>
 
@@ -3272,7 +3276,7 @@ for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
 basic_filebuf&lt;&gt;::seekpos.]</i></p>
 <hr>
 <a name="137"><h3>137.&nbsp;Do use_facet and has_facet look in the global locale?</h3></a><p>
-<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
+<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
 <p>Section 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
 
 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
@@ -3301,7 +3305,7 @@ from section 22.1.1. </p>
 in the standard.</p>
 <hr>
 <a name="139"><h3>139.&nbsp;Optional sequence operation table description unclear</h3></a><p>
-<b>Section:</b>&nbsp;23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Mar 1999</p>
+<b>Section:</b>&nbsp;23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Mar 1999</p>
 <p>The sentence introducing the Optional sequence operation table
 (23.1.1 paragraph 12) has two problems:</p>
 
@@ -3325,7 +3329,7 @@ with:</p>
 </blockquote>
 <hr>
 <a name="141"><h3>141.&nbsp;basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p>
-<b>Section:</b>&nbsp;21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Arch Robison&nbsp; <b>Date:</b>&nbsp;28 Apr 1999</p>
+<b>Section:</b>&nbsp;21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Arch Robison&nbsp; <b>Date:</b>&nbsp;28 Apr 1999</p>
 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
 say:<br>
 <br>
@@ -3347,7 +3351,7 @@ proposed resolution.]</i></p>
 </p>
 <hr>
 <a name="142"><h3>142.&nbsp;lexicographical_compare complexity wrong</h3></a><p>
-<b>Section:</b>&nbsp;25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
+<b>Section:</b>&nbsp;25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
 <p>The lexicographical_compare complexity is specified as:<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp; &quot;At most min((last1 - first1), (last2 - first2))
@@ -3381,7 +3385,7 @@ right! (and Matt states this complexity in his book)</p>
     </blockquote>
 <hr>
 <a name="144"><h3>144.&nbsp;Deque constructor complexity wrong </h3></a><p>
-<b>Section:</b>&nbsp;23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
+<b>Section:</b>&nbsp;23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
 to have complexity requirements which are incorrect, and which contradict the
 complexity requirements for insert(). I suspect that the text in question,
@@ -3413,7 +3417,7 @@ typo):</p>
 </blockquote>
 <hr>
 <a name="146"><h3>146.&nbsp;complex&lt;T&gt; Inserter and Extractor need sentries</h3></a><p>
-<b>Section:</b>&nbsp;26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.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;12 May 1999</p>
+<b>Section:</b>&nbsp;26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;12 May 1999</p>
 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
 
 <blockquote>
@@ -3488,7 +3492,7 @@ follows an &quot;all-or-none&quot; rule.</p>
 as written.</p>
 <hr>
 <a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p>
-<b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
+<b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
 <p>The library had many global functions until 17.4.1.1 [lib.contents]
 paragraph 2 was added: </p>
 
@@ -3552,7 +3556,7 @@ was changed from &quot;non-member&quot; to &quot;global or non-member.
 </p>
 <hr>
 <a name="148"><h3>148.&nbsp;Functions in the example facet BoolNames should be const</h3></a><p>
-<b>Section:</b>&nbsp;22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</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;3 Jun 1999</p>
+<b>Section:</b>&nbsp;22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;3 Jun 1999</p>
 <p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
 do_falsename() functions in the example facet BoolNames should be
 const. The functions they are overriding in
@@ -3566,7 +3570,7 @@ two places:</p>
 </blockquote>
 <hr>
 <a name="150"><h3>150.&nbsp;Find_first_of says integer instead of iterator </h3></a><p>
-<b>Section:</b>&nbsp;25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt McClure&nbsp; <b>Date:</b>&nbsp;30 Jun 1999</p>
+<b>Section:</b>&nbsp;25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt McClure&nbsp; <b>Date:</b>&nbsp;30 Jun 1999</p>
 <p><b>Proposed resolution:</b></p>
 <p>Change 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
 
@@ -3583,7 +3587,7 @@ that for some iterator j in the range [first2, last2) ...</p>
 </blockquote>
 <hr>
 <a name="151"><h3>151.&nbsp;Can't currently clear() empty container</h3></a><p>
-<b>Section:</b>&nbsp;23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;21 Jun 1999</p>
+<b>Section:</b>&nbsp;23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;21 Jun 1999</p>
 <p>For both sequences and associative containers, a.clear() has the
 semantics of erase(a.begin(),a.end()), which is undefined for an empty
 container since erase(q1,q2) requires that q1 be dereferenceable
@@ -3622,7 +3626,7 @@ iterators or certain kinds of iterators is unnecessary.
 </blockquote>
 <hr>
 <a name="152"><h3>152.&nbsp;Typo in <tt>scan_is()</tt> semantics</h3></a><p>
-<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
 because there is no function <tt>is()</tt> which only takes a character as
 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
@@ -3684,7 +3688,7 @@ same paragraphs.]</i></p>
 <hr>
 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The table in paragraph 7 for the length modifier does not list the length
 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
@@ -3699,7 +3703,7 @@ Modifier table to say that for <tt>double</tt> a length modifier
 <hr>
 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>There are conflicting statements about where the class
 <tt>Init</tt> is defined. According to 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
 it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
@@ -3712,7 +3716,7 @@ it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="lib-iost
 the change.</p>
 <hr>
 <a name="156"><h3>156.&nbsp;Typo in <tt>imbue()</tt> description</h3></a><p>
-<b>Section:</b>&nbsp;27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>There is a small discrepancy between the declarations of
 <tt>imbue()</tt>: in 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
 <tt>locale const&amp;</tt> (correct), in 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
@@ -3725,7 +3729,7 @@ const&amp;&quot;.</tt>
 <hr>
 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The default behavior of <tt>setbuf()</tt> is described only for the
 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
 namely to do nothing.  What has to be done in other situations&nbsp;
@@ -3742,7 +3746,7 @@ to: &quot;Default behavior: Does nothing. Returns this.&quot;</p>
 <hr>
 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The description of the meaning of the result of
 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
@@ -3757,7 +3761,7 @@ stream&quot;.</p>
 <hr>
 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
 is not defined. Probably, the referred function is
 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
@@ -3772,7 +3776,7 @@ is the correct spelling.]</i></p>
 <hr>
 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The note in the second paragraph pretends that the first argument
 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
 an object of type <tt>istreambuf_iterator</tt>.</p>
@@ -3787,7 +3791,7 @@ an object of type <tt>istreambuf_iterator</tt>.</p>
 </blockquote>
 <hr>
 <a name="164"><h3>164.&nbsp;do_put() has apparently unused fill argument</h3></a><p>
-<b>Section:</b>&nbsp;22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</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;23 Jul 1999</p>
+<b>Section:</b>&nbsp;22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
 <p>In 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
 as taking a fill character as an argument, but the description of the
 function does not say whether the character is used at all and, if so,
@@ -3857,7 +3861,7 @@ called from what functions and eg to state specifically that flush()
 is allowed to call sync() while other functions are not.]</i></p>
 <hr>
 <a name="168"><h3>168.&nbsp;Typo: formatted vs. unformatted</h3></a><p>
-<b>Section:</b>&nbsp;27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The first paragraph begins with a descriptions what has to be done
 in <i>formatted</i> output functions. Probably this is a typo and the
 paragraph really want to describe unformatted output functions...</p>
@@ -3872,7 +3876,7 @@ sentences, change the word &quot;formatted&quot; to
 </blockquote>
 <hr>
 <a name="169"><h3>169.&nbsp;Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p>
-<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
 especially in view of the restriction that <tt>basic_ostream</tt>
@@ -3894,7 +3898,7 @@ solution is to handle this in <tt>underflow()</tt>.</p>
 <hr>
 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
+<b>Section:</b>&nbsp;27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
 <p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
 <tt>basic_istringstream</tt> (27.7.2 <a href="lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
 <tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
@@ -3964,7 +3968,7 @@ paragraph 14 from:</p>
 <hr>
 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
+<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
 <p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
 argument. However, in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
@@ -3989,7 +3993,7 @@ of <tt>int</tt> in the description of <tt>ignore()</tt> to
 <hr>
 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
+<b>Section:</b>&nbsp;27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
 
 <p>
 In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
@@ -4013,7 +4017,7 @@ as described in issue <a href="lwg-defects.html#172">172</a>.
 <hr>
 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
 </h3></a><p>
-<b>Section:</b>&nbsp;D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
+<b>Section:</b>&nbsp;D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
@@ -4024,7 +4028,7 @@ OFF_T streampos;</tt>&quot; to &quot;<tt>typedef POS_T
 streampos;</tt>&quot;</p>
 <hr>
 <a name="175"><h3>175.&nbsp;Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p>
-<b>Section:</b>&nbsp;D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
+<b>Section:</b>&nbsp;D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
 <p>According to paragraph 8 of this section, the methods
 <tt>basic_streambuf::pubseekpos()</tt>,
 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
@@ -4044,7 +4048,7 @@ argument is not specified.</p>
 </p>
 <hr>
 <a name="176"><h3>176.&nbsp;<tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p>
-<b>Section:</b>&nbsp;D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
+<b>Section:</b>&nbsp;D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
 <p>The &quot;overload&quot; for the function <tt>exceptions()</tt> in
 paragraph 8 gives the impression that there is another function of
 this function defined in class <tt>ios_base</tt>. However, this is not
@@ -4056,7 +4060,7 @@ in clause 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</
 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
 <hr>
 <a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p>
-<b>Section:</b>&nbsp;20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
+<b>Section:</b>&nbsp;20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
 <p>The claim has surfaced in Usenet that expressions such as<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair(&quot;abc&quot;, 3)</tt><br>
@@ -4549,7 +4553,7 @@ the case that users cannot rely on the type of a pointer to a
 nonvirtual member of a standard library class.</p>
 <hr>
 <a name="189"><h3>189.&nbsp;setprecision() not specified correctly</h3></a><p>
-<b>Section:</b>&nbsp;27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;25 Aug 1999</p>
+<b>Section:</b>&nbsp;27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;25 Aug 1999</p>
 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
 and includes a parenthetical note saying that it is the number of
 digits after the decimal point.<br>
@@ -4566,7 +4570,7 @@ correct the statement in 27.4.2.2</p>
 &quot;(number of digits after the decimal point)&quot;.</p>
 <hr>
 <a name="193"><h3>193.&nbsp;Heap operations description incorrect</h3></a><p>
-<b>Section:</b>&nbsp;25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;24 Sep 1999</p>
+<b>Section:</b>&nbsp;25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;24 Sep 1999</p>
 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
 is<br>
 <br>
@@ -4593,7 +4597,7 @@ resolution.</p>
 </blockquote>
 <hr>
 <a name="195"><h3>195.&nbsp;Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p>
-<b>Section:</b>&nbsp;27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</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;13 Oct 1999</p>
+<b>Section:</b>&nbsp;27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;13 Oct 1999</p>
 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
@@ -4768,7 +4772,7 @@ 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>
+<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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
 <p>
 Suppose that <tt>A</tt> is a class that conforms to the
 Allocator requirements of Table 32, and <tt>a</tt> is an
@@ -4791,7 +4795,7 @@ would be over-specification to mandate the return value.
 </p>
 <hr>
 <a name="208"><h3>208.&nbsp;Unnecessary restriction on past-the-end iterators</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;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;02 Feb 2000</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;02 Feb 2000</p>
 <p>In 24.1 paragraph 5, it is stated &quot;. . . Dereferenceable and
 past-the-end values are always non-singular.&quot;</p>
 <p>This places an unnecessary restriction on past-the-end iterators for
@@ -4818,7 +4822,7 @@ iterators.  Null pointers are singular.
 </p>
 <hr>
 <a name="209"><h3>209.&nbsp;basic_string declarations inconsistent</h3></a><p>
-<b>Section:</b>&nbsp;21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Igor Stauder&nbsp; <b>Date:</b>&nbsp;11 Feb 2000</p>
+<b>Section:</b>&nbsp;21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Igor Stauder&nbsp; <b>Date:</b>&nbsp;11 Feb 2000</p>
 <p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
 declarations use a consistent style except for the following functions:</p>
 <blockquote>
@@ -4848,7 +4852,7 @@ change.
 </p>
 <hr>
 <a name="210"><h3>210.&nbsp;distance first and last confused</h3></a><p>
-<b>Section:</b>&nbsp;25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;15 Feb 2000</p>
+<b>Section:</b>&nbsp;25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;15 Feb 2000</p>
 <p>In paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
 <blockquote>
   <p>      In the description of the algorithms operators + and - are used
@@ -4869,7 +4873,7 @@ or change the return to distance(b,a).  The LWG preferred the
 former for consistency.</p>
 <hr>
 <a name="211"><h3>211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3></a><p>
-<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
+<b>Section:</b>&nbsp;21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
 <p>The description of the stream extraction operator for std::string (section
 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
 the case that the operator fails to extract any characters from the input
@@ -4897,7 +4901,7 @@ is.setstate(ios::failbit) which may throw ios_base::failure
 </blockquote>
 <hr>
 <a name="212"><h3>212.&nbsp;Empty range behavior unclear for several algorithms</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;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;26 Feb 2000</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;26 Feb 2000</p>
 <p>The standard doesn't specify what min_element() and max_element() shall
 return if the range is empty (first equals last). The usual implementations
 return last. This problem seems also apply to partition(), stable_partition(),
@@ -4940,7 +4944,7 @@ extending the proposed resolution to lower_bound, upper_bound, and
 equal_range.]</i></p>
 <hr>
 <a name="217"><h3>217.&nbsp;Facets example (Classifying Japanese characters) contains errors</h3></a><p>
-<b>Section:</b>&nbsp;22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</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 Feb 2000</p>
+<b>Section:</b>&nbsp;22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Feb 2000</p>
 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
 must be const in order for it to be callable on a const object (a reference to
@@ -4984,7 +4988,7 @@ declared above.</pre>
 }</pre>
 <hr>
 <a name="220"><h3>220.&nbsp;~ios_base() usage valid?</h3></a><p>
-<b>Section:</b>&nbsp;27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
+<b>Section:</b>&nbsp;27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
 paragraph 2:</p>
 <blockquote>
@@ -5060,7 +5064,7 @@ of digits will not be recognized.  This design decision was made
 deliberately, with full knowledge of that limitation.</p>
 <hr>
 <a name="222"><h3>222.&nbsp;Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p>
-<b>Section:</b>&nbsp;17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;17 Mar 2000</p>
+<b>Section:</b>&nbsp;17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;17 Mar 2000</p>
 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
 <blockquote>
   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
@@ -5102,7 +5106,7 @@ non-normative. The proposed resolution from the LWG clarifies the
 footnote.</p>
 <hr>
 <a name="223"><h3>223.&nbsp;reverse algorithm should use iter_swap rather than swap</h3></a><p>
-<b>Section:</b>&nbsp;25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;21 Mar 2000</p>
+<b>Section:</b>&nbsp;25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;21 Mar 2000</p>
 <p>Shouldn't the effects say &quot;applies iter_swap to all pairs...&quot;?</p>
 <p><b>Proposed resolution:</b></p>
 <p>In 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
@@ -5117,7 +5121,7 @@ footnote.</p>
   </blockquote>
 <hr>
 <a name="224"><h3>224.&nbsp;clear() complexity for associative containers refers to undefined N</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;Ed Brey&nbsp; <b>Date:</b>&nbsp;23 Mar 2000</p>
+<b>Section:</b>&nbsp;23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;23 Mar 2000</p>
 <p>In the associative container requirements table in 23.1.2 paragraph 7,
 a.clear() has complexity &quot;log(size()) + N&quot;. However, the meaning of N
 is not defined.</p>
@@ -5132,7 +5136,7 @@ log(N))</i>.  The text in the standard is probably an incorrect
 cut-and-paste from the range version of <tt>erase</tt>.</p>
 <hr>
 <a name="227"><h3>227.&nbsp;std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p>
-<b>Section:</b>&nbsp;25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
+<b>Section:</b>&nbsp;25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
 <p>25.2.2 reads:</p>
 <blockquote>
   <p>
diff --git a/libstdc++-v3/docs/html/ext/sgiexts.html b/libstdc++-v3/docs/html/ext/sgiexts.html
index 9bb046220387..b35ecaf20eb9 100644
--- a/libstdc++-v3/docs/html/ext/sgiexts.html
+++ b/libstdc++-v3/docs/html/ext/sgiexts.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
    <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, STL, SGI" />
@@ -24,7 +29,7 @@ libstdc++-v3</a></h1>
    for a description).  Not every chapter may have extensions, and the
    extensions may come and go.  Also, this page is incomplete because the
    author is pressed for time.  Check back often; the latest change was on
-   $Date: 2002/09/05 15:47:53 $ (UTC).
+   $Date: 2002/12/16 18:22:57 $ (UTC).
 </p>
 
 <p>Descriptions range from the scanty to the verbose.  You should also check
diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html
index 6d42ebc7ecf2..f472bfc9dc61 100644
--- a/libstdc++-v3/docs/html/faq/index.html
+++ b/libstdc++-v3/docs/html/faq/index.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, libg++, STL" />
@@ -65,7 +70,8 @@
          <li><a href="#3_5"><code>_XOPEN_SOURCE</code> /
                             <code>_GNU_SOURCE</code> / etc is always defined</a>
          </li>
-         <li><a href="#3_6">OS X ctype.h is broken!  How can I hack it?</a> </li>
+         <li><a href="#3_6">OS X ctype.h is broken!  How can I hack it?</a></li>
+         <li><a href="#3_7">Threading is broken on i386</a></li>
       </ol>
    </li>
 
@@ -119,12 +125,14 @@
          ongoing project to implement the ISO 14882 Standard C++ library 
          as described in chapters 17 through 27 and annex D.  As the 
          library reaches stable plateaus, it is captured in a snapshot
-         and released.  The current release is
+         and released.  The latest release is
          <a href="http://gcc.gnu.org/libstdc++/index.html#download">the
-         fourteenth snapshot</a>.  For those who want to see exactly how
+         fourteenth snapshot</a> but newer versions have been included
+         in recent GCC releases.  For those who want to see exactly how
          far the project has come, or just want the latest
          bleeding-edge code, the up-to-date source is available over
-         anonymous CVS, and can even be browsed over the Web (see below). 
+         anonymous CVS, and can even be browsed over the Web (see
+         <a href="#1_4">1.4</a> below). 
       </p>
       <p>The older libstdc++-v2 project is no longer maintained; the code
          has been completely replaced and rewritten.
@@ -490,6 +498,18 @@ which is no longer available, thanks deja...-->
          link to the solution.</a>
       </p>
 
+<hr />
+   <h2><a name="3_7">Threading is broken on i386</a></h2>
+      <p>Support for atomic integer operations is/was broken on i386
+         platforms.  The assembly code accidentally used opcodes that are
+         only available on the i486 and later.  So if you configured GCC
+         to target, for example, i386-linux, but actually used the programs
+	 on an i686, then you would encounter no problems.  Only when
+	 actually running the code on a i386 will the problem appear.  
+      </p>
+      <p>This is fixed in 3.2.2.
+      </p>
+
 <hr />
 <h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
    <em>Note that this section can get rapdily outdated -- such is the
@@ -857,6 +877,34 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
          that of other headers whose directories are not searched directly,
          e.g., <code>&lt;sys/stat.h&gt;</code>, <code>&lt;X11/Xlib.h&gt;</code>.
       </p>
+
+      <p>The extensions are no longer in the global or <code>std</code>
+         namespaces, instead they are declared in the <code>__gnu_cxx</code>
+         namespace. For maximum portability, consider defining a namespace
+         alias to use to talk about extensions, e.g.:
+      </p>
+      <pre>
+      #ifdef __GNUC__
+      #if __GNUC__ &lt; 3
+        #include &lt;hash_map.h&gt;
+        namespace Sgi { using ::hash_map; }; // inherit globals
+      #else
+        #include &lt;ext/hash_map&gt;
+        #if __GNUC_MINOR__ == 0
+          namespace Sgi = std;               // GCC 3.0
+        #else
+          namespace Sgi = ::__gnu_cxx;       // GCC 3.1 and later
+        #endif
+      #endif
+      #else      // ...  there are other compilers, right?
+        namespace Sgi = std;
+      #endif
+
+      Sgi::hash_map&lt;int,int&gt; my_map; </pre>
+      <p>This is a bit cleaner than defining typedefs for all the
+         instantiations you might need.
+      </p>
+
       <p>Extensions to the library have
          <a href="../ext/howto.html">their own page</a>.
       </p>
diff --git a/libstdc++-v3/docs/html/faq/index.txt b/libstdc++-v3/docs/html/faq/index.txt
index 59632af35d47..3ea90597d43a 100644
--- a/libstdc++-v3/docs/html/faq/index.txt
+++ b/libstdc++-v3/docs/html/faq/index.txt
@@ -34,31 +34,32 @@
          4. [24]I can't use 'long long' on Solaris
          5. [25]_XOPEN_SOURCE / _GNU_SOURCE / etc is always defined
          6. [26]OS X ctype.h is broken! How can I hack it?
-    4. [27]Known Bugs and Non-Bugs
-         1. [28]What works already?
-         2. [29]Bugs in gcc/g++ (not libstdc++-v3)
-         3. [30]Bugs in the C++ language/lib specification
-         4. [31]Things in libstdc++ that only look like bugs
-               o [32]reopening a stream fails
-               o [33]-Weffc++ complains too much
-               o [34]"ambiguous overloads" after including an old-style
+         7. [27]Threading is broken on i386
+    4. [28]Known Bugs and Non-Bugs
+         1. [29]What works already?
+         2. [30]Bugs in gcc/g++ (not libstdc++-v3)
+         3. [31]Bugs in the C++ language/lib specification
+         4. [32]Things in libstdc++ that only look like bugs
+               o [33]reopening a stream fails
+               o [34]-Weffc++ complains too much
+               o [35]"ambiguous overloads" after including an old-style
                  header
-               o [35]The g++-3 headers are not ours
-               o [36]compilation errors from streambuf.h
-               o [37]errors about *Concept and constraints in the STL...
-               o [38]program crashes when using library code in a
+               o [36]The g++-3 headers are not ours
+               o [37]compilation errors from streambuf.h
+               o [38]errors about *Concept and constraints in the STL...
+               o [39]program crashes when using library code in a
                  dynamically-loaded library
-         5. [39]Aw, that's easy to fix!
-    5. [40]Miscellaneous
-         1. [41]string::iterator is not char*; vector<T>::iterator is not
+         5. [40]Aw, that's easy to fix!
+    5. [41]Miscellaneous
+         1. [42]string::iterator is not char*; vector<T>::iterator is not
             T*
-         2. [42]What's next after libstdc++-v3?
-         3. [43]What about the STL from SGI?
-         4. [44]Extensions and Backward Compatibility
-         5. [45][removed]
-         6. [46]Is libstdc++-v3 thread-safe?
-         7. [47]How do I get a copy of the ISO C++ Standard?
-         8. [48]What's an ABI and why is it so messy?
+         2. [43]What's next after libstdc++-v3?
+         3. [44]What about the STL from SGI?
+         4. [45]Extensions and Backward Compatibility
+         5. [46][removed]
+         6. [47]Is libstdc++-v3 thread-safe?
+         7. [48]How do I get a copy of the ISO C++ Standard?
+         8. [49]What's an ABI and why is it so messy?
      _________________________________________________________________
 
                             1.0 General Information
@@ -68,18 +69,19 @@
    The GNU Standard C++ Library v3 is an ongoing project to implement the
    ISO 14882 Standard C++ library as described in chapters 17 through 27
    and annex D. As the library reaches stable plateaus, it is captured in
-   a snapshot and released. The current release is [49]the fourteenth
-   snapshot. For those who want to see exactly how far the project has
-   come, or just want the latest bleeding-edge code, the up-to-date
-   source is available over anonymous CVS, and can even be browsed over
-   the Web (see below).
+   a snapshot and released. The latest release is [50]the fourteenth
+   snapshot but newer versions have been included in recent GCC releases.
+   For those who want to see exactly how far the project has come, or
+   just want the latest bleeding-edge code, the up-to-date source is
+   available over anonymous CVS, and can even be browsed over the Web
+   (see [51]1.4 below).
 
    The older libstdc++-v2 project is no longer maintained; the code has
-   been completely replaced and rewritten. [50]If you are using V2, then
+   been completely replaced and rewritten. [52]If you are using V2, then
    you need to report bugs to your system vendor, not to the V3 list.
 
    A more formal description of the V3 goals can be found in the official
-   [51]design document.
+   [53]design document.
      _________________________________________________________________
 
 1.2 Why should I use libstdc++?
@@ -92,8 +94,8 @@
 
    The GNU C/C++/FORTRAN/<pick-a-language> compiler (gcc, g++, etc) is
    widely considered to be one of the leading compilers in the world. Its
-   development has recently been taken over by the [52]GCC team. All of
-   the rapid development and near-legendary [53]portability that are the
+   development has recently been taken over by the [54]GCC team. All of
+   the rapid development and near-legendary [55]portability that are the
    hallmarks of an open-source project are being applied to libstdc++.
 
    That means that all of the Standard classes and functions (such as
@@ -111,16 +113,16 @@
 
    Development and discussion is held on the libstdc++ mailing list.
    Subscribing to the list, or searching the list archives, is open to
-   everyone. You can read instructions for doing so on the [54]homepage.
+   everyone. You can read instructions for doing so on the [56]homepage.
    If you have questions, ideas, code, or are just curious, sign up!
      _________________________________________________________________
 
 1.4 How do I get libstdc++?
 
-   The fourteenth (and latest) snapshot of libstdc++-v3 is [55]available
+   The fourteenth (and latest) snapshot of libstdc++-v3 is [57]available
    via ftp.
 
-   The [56]homepage has instructions for retrieving the latest CVS
+   The [58]homepage has instructions for retrieving the latest CVS
    sources, and for browsing the CVS sources over the web.
 
    The subset commonly known as the Standard Template Library (chapters
@@ -136,7 +138,7 @@
 
 1.6 How do I contribute to the effort?
 
-   Here is [57]a page devoted to this topic. Subscribing to the mailing
+   Here is [59]a page devoted to this topic. Subscribing to the mailing
    list (see above, or the homepage) is a very good idea if you have
    something to contribute, or if you have spare time and want to help.
    Contributions don't have to be in the form of source code; anybody who
@@ -171,11 +173,11 @@
    extracted into an updated utilities library, but nobody has stated
    such a project yet.
 
-   (The [58]Boost site houses free C++ libraries that do varying things,
+   (The [60]Boost site houses free C++ libraries that do varying things,
    and happened to be started by members of the Standards Committee.
    Certain "useful stuff" classes will probably migrate there.)
 
-   For the bold and/or desperate, the [59]GCC FAQ describes where to find
+   For the bold and/or desperate, the [61]GCC FAQ describes where to find
    the last libg++ source.
      _________________________________________________________________
 
@@ -185,16 +187,16 @@
    remains unanswered, then just ask the mailing list. At present, you do
    not need to be subscribed to the list to send a message to it. More
    information is available on the homepage (including how to browse the
-   list archives); to send to the list, use [60]libstdc++@gcc.gnu.org.
+   list archives); to send to the list, use [62]libstdc++@gcc.gnu.org.
 
    If you have a question that you think should be included here, or if
-   you have a question about a question/answer here, contact [61]Phil
-   Edwards or [62]Gabriel Dos Reis.
+   you have a question about a question/answer here, contact [63]Phil
+   Edwards or [64]Gabriel Dos Reis.
      _________________________________________________________________
 
 1.9 What are the license terms for libstdc++-v3?
 
-   See [63]our license description for these and related questions.
+   See [65]our license description for these and related questions.
      _________________________________________________________________
 
                                2.0 Installation
@@ -211,13 +213,13 @@
      * The GNU Autotools are needed if you are messing with the configury
        or makefiles.
 
-   The file [64]documentation.html provides a good overview of the steps
+   The file [66]documentation.html provides a good overview of the steps
    necessary to build, install, and use the library. Instructions for
    configuring the library with new flags such as --enable-threads are
    there also, as well as patches and instructions for working with GCC
    2.95.
 
-   The top-level install.html and [65]RELEASE-NOTES files contain the
+   The top-level install.html and [67]RELEASE-NOTES files contain the
    exact build and installation instructions. You may wish to browse
    those files over CVSweb ahead of time to get a feel for what's
    required. RELEASE-NOTES is located in the ".../docs/17_intro/"
@@ -234,8 +236,8 @@
 
    The Concurrent Versions System is one of several revision control
    packages. It was selected for GNU projects because it's free (speech),
-   free (beer), and very high quality. The [66]CVS entry in the GNU
-   software catalogue has a better description as well as a [67]link to
+   free (beer), and very high quality. The [68]CVS entry in the GNU
+   software catalogue has a better description as well as a [69]link to
    the makers of CVS.
 
    The "anonymous client checkout" feature of CVS is similar to anonymous
@@ -286,7 +288,7 @@
    people don't like it, so here are two pseudo-solutions:
 
    If the only functions from libstdc++.a which you need are language
-   support functions (those listed in [68]clause 18 of the standard,
+   support functions (those listed in [70]clause 18 of the standard,
    e.g., new and delete), then try linking against libsupc++.a (usually
    specifying -lsupc++ when calling g++ for the final link step will do
    it). This library contains only those support routines, one per object
@@ -381,7 +383,7 @@
    - < /dev/null" to display a list of predefined macros for any
    particular installation.
 
-   This has been discussed on the mailing lists [69]quite a bit.
+   This has been discussed on the mailing lists [71]quite a bit.
 
    This method is something of a wart. We'd like to find a cleaner
    solution, but nobody yet has contributed the time.
@@ -390,8 +392,20 @@
 3.6 OS X ctype.h is broken! How can I hack it?
 
    This is a long-standing bug in the OS X support. Fortunately, the
-   patch is quite simple, and well-known. [70]Here's a link to the
+   patch is quite simple, and well-known. [72]Here's a link to the
    solution.
+     _________________________________________________________________
+
+Threading is broken on i386
+
+   Support for atomic integer operations is/was broken on i386 platforms.
+   The assembly code accidentally used opcodes that are only available on
+   the i486 and later. So if you configured GCC to target, for example,
+   i386-linux, but actually used the programs on an i686, then you would
+   encounter no problems. Only when actually running the code on a i386
+   will the problem appear.
+
+   This is fixed in 3.2.2.
      _________________________________________________________________
 
                           4.0 Known Bugs and Non-Bugs
@@ -403,7 +417,7 @@
 
    For 3.0.1, the most common "bug" is an apparently missing "../" in
    include/Makefile, resulting in files like gthr.h and gthr-single.h not
-   being found. Please read [71]the configuration instructions for GCC,
+   being found. Please read [73]the configuration instructions for GCC,
    specifically the part about configuring in a separate build directory,
    and how strongly recommended it is. Building in the source directory
    is fragile, is rarely tested, and tends to break, as in this case.
@@ -411,7 +425,7 @@
 
    For 3.1, the most common "bug" is a parse error when using <fstream>,
    ending with a message, "bits/basic_file.h:52: parse error before `{'
-   token." Please read [72]the installation instructions for GCC,
+   token." Please read [74]the installation instructions for GCC,
    specifically the part about not installing newer versions on top of
    older versions. If you install 3.1 over a 3.0.x release, then the
    wrong basic_file.h header will be found (its location changed between
@@ -480,30 +494,30 @@ New:
    libstdc++. If you are experiencing one of these problems, you can find
    more information on the libstdc++ and the GCC mailing lists.
 
-   Before reporting a bug, examine the [73]bugs database with the
+   Before reporting a bug, examine the [75]bugs database with the
    category set to "libstdc++". The BUGS file in the source tree also
    tracks known serious problems.
      * Debugging is problematic, due to bugs in line-number generation
        (mostly fixed in the compiler) and gdb lagging behind the compiler
        (lack of personnel). We recommend configuring the compiler using
        --with-dwarf2 if the DWARF2 debugging format is not already the
-       default on your platform. Also, [74]changing your GDB settings can
+       default on your platform. Also, [76]changing your GDB settings can
        have a profound effect on your C++ debugging experiences. :-)
      _________________________________________________________________
 
 4.3 Bugs in the C++ language/lib specification
 
-   Yes, unfortunately, there are some. In a [75]message to the list,
+   Yes, unfortunately, there are some. In a [77]message to the list,
    Nathan Myers announced that he has started a list of problems in the
    ISO C++ Standard itself, especially with regard to the chapters that
-   concern the library. The list itself is [76]posted on his website.
+   concern the library. The list itself is [78]posted on his website.
    Developers who are having problems interpreting the Standard may wish
    to consult his notes.
 
    For those people who are not part of the ISO Library Group (i.e.,
    nearly all of us needing to read this page in the first place :-), a
-   public list of the library defects is occasionally published [77]here.
-   Some of these have resulted in [78]code changes.
+   public list of the library defects is occasionally published [79]here.
+   Some of these have resulted in [80]code changes.
      _________________________________________________________________
 
 4.4 Things in libstdc++ that only look like bugs
@@ -535,7 +549,7 @@ New:
    state on the previous file. The reason is that the state flags are not
    cleared on a successful call to open(). The standard unfortunately did
    not specify behavior in this case, and to everybody's great sorrow,
-   the [79]proposed LWG resolution (see DR #22) is to leave the flags
+   the [81]proposed LWG resolution (see DR #22) is to leave the flags
    unchanged. You must insert a call to fs.clear() between the calls to
    close() and open(), and then everything will work like we all expect
    it to work.
@@ -545,7 +559,7 @@ New:
    same namespace as other comparison functions (e.g., 'using' them and
    the <iterator> header), then you will suddenly be faced with huge
    numbers of ambiguity errors. This was discussed on the -v3 list;
-   Nathan Myers [80]sums things up here. The collisions with
+   Nathan Myers [82]sums things up here. The collisions with
    vector/string iterator types have been fixed for 3.1.
 
   The g++-3 headers are not ours
@@ -553,7 +567,7 @@ New:
    If you have found an extremely broken header file which is causing
    problems for you, look carefully before submitting a "high" priority
    bug report (which you probably shouldn't do anyhow; see the last
-   paragraph of the page describing [81]the GCC bug database).
+   paragraph of the page describing [83]the GCC bug database).
 
    If the headers are in ${prefix}/include/g++-3, or if the installed
    library's name looks like libstdc++-2.10.a or libstdc++-libc6-2.10.so,
@@ -563,7 +577,7 @@ New:
 
    Currently our header files are installed in ${prefix}/include/g++-v3
    (see the 'v'?). This may change with the next release of GCC, as it
-   may be too confusing, but [82]the question has not yet been decided.
+   may be too confusing, but [84]the question has not yet been decided.
 
    glibc If you're on a GNU/Linux system and have just upgraded to glibc
    2.2, but are still using gcc 2.95.2, then you should have read the
@@ -576,7 +590,7 @@ type has changed in glibc 2.2.  The patch is at
 http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
 
 
-   Note that 2.95.x shipped with the [83]old v2 library which is no
+   Note that 2.95.x shipped with the [85]old v2 library which is no
    longer maintained. Also note that gcc 2.95.3 fixes this problem, but
    requires a separate patch for libstdc++-v3.
 
@@ -589,7 +603,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
    visibility, or you just plain forgot, etc).
 
    More information, including how to optionally enable/disable the
-   checks, is available [84]here.
+   checks, is available [86]here.
 
    dlopen/dlsym If you are using the C++ library across
    dynamically-loaded objects, make certain that you are passing the
@@ -611,16 +625,16 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
 
    If you have found a bug in the library and you think you have a
    working fix, then send it in! The main GCC site has a page on
-   [85]submitting patches that covers the procedure, but for libstdc++
+   [87]submitting patches that covers the procedure, but for libstdc++
    you should also send the patch to our mailing list in addition to the
-   GCC patches mailing list. The libstdc++ [86]contributors' page also
+   GCC patches mailing list. The libstdc++ [88]contributors' page also
    talks about how to submit patches.
 
    In addition to the description, the patch, and the ChangeLog entry, it
    is a Good Thing if you can additionally create a small test program to
    test for the presence of the bug that your patch fixes. Bugs have a
    way of being reintroduced; if an old bug creeps back in, it will be
-   caught immediately by the [87]testsuite -- but only if such a test
+   caught immediately by the [89]testsuite -- but only if such a test
    exists.
      _________________________________________________________________
 
@@ -654,7 +668,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
        libstdc++. Some of that is already happening, see 4.2. Some of
        those changes are being predicted by the library maintainers, and
        we add code to the library based on what the current proposed
-       resolution specifies. Those additions are listed in [88]the
+       resolution specifies. Those additions are listed in [90]the
        extensions page.
     2. Performance tuning. Lots of performance tuning. This too is
        already underway for post-3.0 releases, starting with memory
@@ -670,13 +684,13 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
        type from C99.) Bugfixes and rewrites (to improve or fix thread
        safety, for instance) will of course be a continuing task.
 
-   [89]This question about the next libstdc++ prompted some brief but
-   interesting [90]speculation.
+   [91]This question about the next libstdc++ prompted some brief but
+   interesting [92]speculation.
      _________________________________________________________________
 
 5.3 What about the STL from SGI?
 
-   The [91]STL from SGI, version 3.3, was the most recent merge of the
+   The [93]STL from SGI, version 3.3, was the most recent merge of the
    STL codebase. The code in libstdc++ contains many fixes and changes,
    and it is very likely that the SGI code is no longer under active
    development. We expect that no future merges will take place.
@@ -700,7 +714,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
    headers whose directories are not searched directly, e.g.,
    <sys/stat.h>, <X11/Xlib.h>.
 
-   Extensions to the library have [92]their own page.
+   Extensions to the library have [94]their own page.
      _________________________________________________________________
 
 5.5 [removed]
@@ -749,8 +763,8 @@ a
    otherwise documented as safe, do not assume that two threads may
    access a shared standard library object at the same time.
 
-   See chapters [93]17 (library introduction), [94]23 (containers), and
-   [95]27 (I/O) for more information.
+   See chapters [95]17 (library introduction), [96]23 (containers), and
+   [97]27 (I/O) for more information.
      _________________________________________________________________
 
 5.7 How do I get a copy of the ISO C++ Standard?
@@ -761,12 +775,12 @@ a
    their two-meeting commitment for voting rights, may get a copy of the
    standard from their respective national standards organization. In the
    USA, this national standards organization is ANSI and their website is
-   right [96]here. (And if you've already registered with them, clicking
-   this link will take you to directly to the place where you can [97]buy
+   right [98]here. (And if you've already registered with them, clicking
+   this link will take you to directly to the place where you can [99]buy
    the standard on-line.
 
-   Who is your country's member body? Visit the [98]ISO homepage and find
-   out!
+   Who is your country's member body? Visit the [100]ISO homepage and
+   find out!
      _________________________________________________________________
 
 5.8 What's an ABI and why is it so messy?
@@ -816,8 +830,8 @@ a
    encompasses the standard library.
      _________________________________________________________________
 
-   See [99]license.html for copying conditions. Comments and suggestions
-   are welcome, and may be sent to [100]the libstdc++ mailing list. 
+   See [101]license.html for copying conditions. Comments and suggestions
+   are welcome, and may be sent to [102]the libstdc++ mailing list. 
 
 References
 
@@ -847,77 +861,79 @@ References
   24. ../faq/index.html#3_4
   25. ../faq/index.html#3_5
   26. ../faq/index.html#3_6
-  27. ../faq/index.html#4_0
-  28. ../faq/index.html#4_1
-  29. ../faq/index.html#4_2
-  30. ../faq/index.html#4_3
-  31. ../faq/index.html#4_4
-  32. ../faq/index.html#4_4_iostreamclear
-  33. ../faq/index.html#4_4_Weff
-  34. ../faq/index.html#4_4_rel_ops
-  35. ../faq/index.html#4_4_interface
-  36. ../faq/index.html#4_4_glibc
-  37. ../faq/index.html#4_4_checks
-  38. ../faq/index.html#4_4_dlsym
-  39. ../faq/index.html#4_5
-  40. ../faq/index.html#5_0
-  41. ../faq/index.html#5_1
-  42. ../faq/index.html#5_2
-  43. ../faq/index.html#5_3
-  44. ../faq/index.html#5_4
-  45. ../faq/index.html#5_5
-  46. ../faq/index.html#5_6
-  47. ../faq/index.html#5_7
-  48. ../faq/index.html#5_8
-  49. http://gcc.gnu.org/libstdc++/index.html#download
-  50. ../faq/index.html#4_4_interface
-  51. ../17_intro/DESIGN
-  52. http://gcc.gnu.org/
-  53. http://gcc.gnu.org/gcc-3.0/buildstat.html
-  54. http://gcc.gnu.org/libstdc++/
-  55. http://gcc.gnu.org/libstdc++/index.html#download
+  27. ../faq/index.html#3_7
+  28. ../faq/index.html#4_0
+  29. ../faq/index.html#4_1
+  30. ../faq/index.html#4_2
+  31. ../faq/index.html#4_3
+  32. ../faq/index.html#4_4
+  33. ../faq/index.html#4_4_iostreamclear
+  34. ../faq/index.html#4_4_Weff
+  35. ../faq/index.html#4_4_rel_ops
+  36. ../faq/index.html#4_4_interface
+  37. ../faq/index.html#4_4_glibc
+  38. ../faq/index.html#4_4_checks
+  39. ../faq/index.html#4_4_dlsym
+  40. ../faq/index.html#4_5
+  41. ../faq/index.html#5_0
+  42. ../faq/index.html#5_1
+  43. ../faq/index.html#5_2
+  44. ../faq/index.html#5_3
+  45. ../faq/index.html#5_4
+  46. ../faq/index.html#5_5
+  47. ../faq/index.html#5_6
+  48. ../faq/index.html#5_7
+  49. ../faq/index.html#5_8
+  50. http://gcc.gnu.org/libstdc++/index.html#download
+  51. ../faq/index.html#1_4
+  52. ../faq/index.html#4_4_interface
+  53. ../17_intro/DESIGN
+  54. http://gcc.gnu.org/
+  55. http://gcc.gnu.org/gcc-3.0/buildstat.html
   56. http://gcc.gnu.org/libstdc++/
-  57. ../17_intro/contribute.html
-  58. http://www.boost.org/
-  59. http://gcc.gnu.org/fom_serv/cache/33.html
-  60. mailto:libstdc++@gcc.gnu.org
-  61. mailto:pme@gcc.gnu.org
-  62. mailto:gdr@gcc.gnu.org
-  63. ../17_intro/license.html
-  64. ../documentation.html
-  65. ../17_intro/RELEASE-NOTES
-  66. http://www.gnu.org/software/cvs/cvs.html
-  67. http://www.cvshome.org/
-  68. ../18_support/howto.html
-  69. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
-  70. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
-  71. http://gcc.gnu.org/install/configure.html
-  72. http://gcc.gnu.org/install/
-  73. http://gcc.gnu.org/bugs.html
-  74. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
-  75. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
-  76. http://www.cantrip.org/draft-bugs.txt
-  77. http://anubis.dkuug.dk/jtc1/sc22/wg21/
-  78. ../faq/index.html#5_2
-  79. ../ext/howto.html#5
-  80. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
-  81. http://gcc.gnu.org/gnatswrite.html
-  82. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
-  83. ../faq/index.html#4_4_interface
-  84. ../19_diagnostics/howto.html#3
-  85. http://gcc.gnu.org/contribute.html
-  86. ../17_intro/contribute.html
-  87. ../faq/index.html#2_4
-  88. ../ext/howto.html#5
-  89. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
-  90. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
-  91. http://www.sgi.com/Technology/STL/
-  92. ../ext/howto.html
-  93. ../17_intro/howto.html#3
-  94. ../23_containers/howto.html#3
-  95. ../27_io/howto.html#9
-  96. http://www.ansi.org/
-  97. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
-  98. http://www.iso.ch/
-  99. ../17_intro/license.html
- 100. mailto:libstdc++@gcc.gnu.org
+  57. http://gcc.gnu.org/libstdc++/index.html#download
+  58. http://gcc.gnu.org/libstdc++/
+  59. ../17_intro/contribute.html
+  60. http://www.boost.org/
+  61. http://gcc.gnu.org/fom_serv/cache/33.html
+  62. mailto:libstdc++@gcc.gnu.org
+  63. mailto:pme@gcc.gnu.org
+  64. mailto:gdr@gcc.gnu.org
+  65. ../17_intro/license.html
+  66. ../documentation.html
+  67. ../17_intro/RELEASE-NOTES
+  68. http://www.gnu.org/software/cvs/cvs.html
+  69. http://www.cvshome.org/
+  70. ../18_support/howto.html
+  71. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
+  72. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
+  73. http://gcc.gnu.org/install/configure.html
+  74. http://gcc.gnu.org/install/
+  75. http://gcc.gnu.org/bugs.html
+  76. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
+  77. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
+  78. http://www.cantrip.org/draft-bugs.txt
+  79. http://anubis.dkuug.dk/jtc1/sc22/wg21/
+  80. ../faq/index.html#5_2
+  81. ../ext/howto.html#5
+  82. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
+  83. http://gcc.gnu.org/gnatswrite.html
+  84. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
+  85. ../faq/index.html#4_4_interface
+  86. ../19_diagnostics/howto.html#3
+  87. http://gcc.gnu.org/contribute.html
+  88. ../17_intro/contribute.html
+  89. ../faq/index.html#2_4
+  90. ../ext/howto.html#5
+  91. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
+  92. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
+  93. http://www.sgi.com/Technology/STL/
+  94. ../ext/howto.html
+  95. ../17_intro/howto.html#3
+  96. ../23_containers/howto.html#3
+  97. ../27_io/howto.html#9
+  98. http://www.ansi.org/
+  99. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
+ 100. http://www.iso.ch/
+ 101. ../17_intro/license.html
+ 102. mailto:libstdc++@gcc.gnu.org
diff --git a/libstdc++-v3/docs/html/install.html b/libstdc++-v3/docs/html/install.html
index f91e6c7f2d71..e4295aaa4de3 100644
--- a/libstdc++-v3/docs/html/install.html
+++ b/libstdc++-v3/docs/html/install.html
@@ -1,4 +1,9 @@
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+          PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
    <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
    <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
@@ -286,6 +291,7 @@
    interest to library maintainers and system integrators. As such,
    these tests may not work on all cpu and host combinations. These
    options include, but are not necessarily limited to, the following:
+   </p>
 
    <p>The library ABI can be tested using</p>
    <pre>
@@ -295,7 +301,7 @@
    the default dejagnu test harness</p>
    <pre>
    make check-script</pre>
-   or
+   <p>or</p>
    <pre>
    make check-script-install</pre>