re PR libstdc++/59698 (The type of NULL is described elsewhere)

	PR libstdc++/59698
	* doc/xml/manual/status_cxx1998.xml (iso.1998.specific): Markup
	and stylistic improvements.
	* doc/xml/manual/codecvt.xml (std.localization.facet.codecvt): Likewise
	and update for C++11.
	* doc/xml/manual/ctype.xml (std.localization.facet.ctype): Likewise.

From-SVN: r206524

libstdc++-v3/ChangeLog

+2014-01-10  Jonathan Wakely  <jwakely@redhat.com>
+
+	PR libstdc++/59698
+	* doc/xml/manual/status_cxx1998.xml (iso.1998.specific): Markup
+	and stylistic improvements.
+	* doc/xml/manual/codecvt.xml (std.localization.facet.codecvt): Likewise
+	and update for C++11.
+	* doc/xml/manual/ctype.xml (std.localization.facet.ctype): Likewise.
+
 2014-01-09  Jonathan Wakely  <jwakely@redhat.com>
 
 	PR libstdc++/59738

libstdc++-v3/doc/xml/manual/ctype.xml

@@ -18,10 +18,10 @@
     
 
 <para>
-For the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt; ,
+For the required specialization <classname>codecvt&lt;wchar_t, char, mbstate_t&gt;</classname>,
 conversions are made between the internal character set (always UCS4
 on GNU/Linux) and whatever the currently selected locale for the
-LC_CTYPE category implements.
+<code>LC_CTYPE</code> category implements.
 </para>
 
 <para>
@@ -45,8 +45,10 @@ ctype&lt;wchar_t&gt;
 <para>
 This specialization, by specifying all the template parameters, pretty
 much ties the hands of implementors. As such, the implementation is
-straightforward, involving mcsrtombs for the conversions between char
-to wchar_t and wcsrtombs for conversions between wchar_t and char.
+straightforward, involving <function>mcsrtombs</function> for the
+conversions between <type>char</type> to <type>wchar_t</type> and
+<function>wcsrtombs</function> for conversions between <type>wchar_t</type>
+and <type>char</type>.
 </para>
 
 <para>
@@ -69,7 +71,8 @@ characters.
 
    <listitem>
    <para>
-   How to deal with different types than char, wchar_t? </para></listitem>
+   How to deal with types other than <type>char</type>, <type>wchar_t</type>?
+   </para></listitem>
 
    <listitem><para>
    Overlap between codecvt/ctype: narrow/widen
@@ -77,8 +80,8 @@ characters.
 
    <listitem>
      <para>
-       Mask typedef in codecvt_base, argument types in codecvt.  what
-       is know about this type?
+       <type>mask</type> typedef in <classname>codecvt_base</classname>,
+       argument types in <type>codecvt</type>.  what is know about this type?
    </para></listitem>
 
    <listitem>
@@ -95,10 +98,11 @@ characters.
 
    <listitem>
      <para>
-       Get the ctype&lt;wchar_t&gt;::mask stuff under control. Need to
-       make some kind of static table, and not do lookup every time
-       somebody hits the do_is... functions. Too bad we can't just
-       redefine mask for ctype&lt;wchar_t&gt;
+       Get the <type>ctype&lt;wchar_t&gt;::mask</type> stuff under control.
+       Need to make some kind of static table, and not do lookup every time
+       somebody hits the <code>do_is...</code> functions. Too bad we can't
+       just redefine <type>mask</type> for
+       <classname>ctype&lt;wchar_t&gt;</classname>
    </para></listitem>
 
    <listitem>

libstdc++-v3/doc/xml/manual/status_cxx1998.xml

@@ -1075,7 +1075,7 @@ particular release.
 	in the sections where the function itself occurs.
    -->
    <para><emphasis>[18.1]/4</emphasis> The type of <code>NULL</code> is described
-      <link linkend="std.support.types.null">here</link>.
+      under <link linkend="std.support.types.null">Support</link>.
    </para>
    <para><emphasis>[18.3]/8</emphasis> Even though it's listed in the library
       sections, libstdc++ has zero control over what the cleanup code hands
@@ -1107,9 +1107,10 @@ particular release.
       implementations, any requirements imposed on allocators by containers
       beyond those requirements that appear in Table 32, and the semantics
       of containers and algorithms when allocator instances compare
-      non-equal, are implementation-defined."</emphasis>  As yet we don't
-      have any allocators which compare non-equal, so we can't describe how
-      they behave.
+      non-equal, are implementation-defined."</emphasis>  There is experimental
+      support for non-equal allocators in the standard containers in C++98
+      mode. There are no additional requirements on allocators. It is undefined
+      behaviour to swap two containers if their allocators are not equal.
    </para>
    <para><emphasis>[21.1.3.1]/3,4</emphasis>,
       <emphasis>[21.1.3.2]/2</emphasis>,
@@ -1121,16 +1122,16 @@ particular release.
       here would defeat the purpose.  :-)
    </para>
    <para><emphasis>[21.1.3.1]/5</emphasis> I don't really know about
-      the mbstate_t stuff... see
-      the <link linkend="std.localization.facet.codecvt">chapter 22
+      the <type>mbstate_t</type> stuff... see
+      the <link linkend="std.localization.facet.codecvt"><code>codecvt</code>
       notes</link> for what does exist.
    </para>
    <para><emphasis>[22.*]</emphasis> Anything and everything we have on locale
-      implementation will be described
-      <link linkend="std.localization.locales.locale">over here</link>.
+      implementation will be described under
+      <link linkend="std.localization.locales.locale">Localization</link>.
    </para>
    <para><emphasis>[26.2.8]/9</emphasis> I have no idea what
-      <code>complex&lt;T&gt;</code>'s pow(0,0) returns.
+      <code>complex&lt;T&gt;</code>'s <code>pow(0,0)</code> returns.
    </para>
    <para><emphasis>[27.4.2.4]/2</emphasis> Calling
       <code>std::ios_base::sync_with_stdio</code> after I/O has already been
@@ -1138,8 +1139,8 @@ particular release.
       flush the buffers, and <!-- this line might go away -->
       destroy and recreate the underlying buffer instances.  Whether or not
       the previously-written I/O is destroyed in this process depends mostly
-      on the --enable-libio choice:  for stdio, if the written data is
-      already in the stdio buffer, the data may be completely safe!
+      on the <code>--enable-libio</code> choice:  for stdio, if the written
+      data is already in the stdio buffer, the data may be completely safe!
    </para>
    <para><emphasis>[27.6.1.1.2]</emphasis>,
       <emphasis>[27.6.2.3]</emphasis> The I/O sentry ctor and dtor can perform
@@ -1148,8 +1149,8 @@ particular release.
    </para>
    <para><emphasis>[27.7.1.3]/16</emphasis>,
       <emphasis>[27.8.1.4]/10</emphasis>
-      The effects of <code>pubsetbuf/setbuf</code> are described
-      <link linkend="std.io">in this chapter</link>.
+      The effects of <code>pubsetbuf/setbuf</code> are described in the
+      <link linkend="std.io">Input and Output</link> chapter.
    </para>
    <para><emphasis>[27.8.1.4]/16</emphasis> Calling <code>fstream::sync</code> when
       a get area exists will... whatever <code>fflush()</code> does, I think.