https://gcc.gnu.org/g:b26033d579a9df55f38f3b9ff8400c21f2a5717d
commit r16-3560-gb26033d579a9df55f38f3b9ff8400c21f2a5717d
Author: Tomasz Kamiński <tkami...@redhat.com>
Date: Mon Sep 1 16:11:05 2025 +0200
libstdc++: Add stable names to C++98 implementation-defined docs.
Stable names are based on C++03 standard document, and some of then were
changed since then.
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerated the file.
* doc/xml/manual/status_cxx1998.xml: Add stable name to
each entry.
Reviewed-by: Jonathan Wakely <jwak...@redhat.com>
Signed-off-by: Tomasz Kamiński <tkami...@redhat.com>
Diff:
---
libstdc++-v3/doc/html/manual/status.html | 103 +++++++++++++------------
libstdc++-v3/doc/xml/manual/status_cxx1998.xml | 103 +++++++++++++------------
2 files changed, 108 insertions(+), 98 deletions(-)
diff --git a/libstdc++-v3/doc/html/manual/status.html
b/libstdc++-v3/doc/html/manual/status.html
index 5ca35217f66f..f3d4a229daf6 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -69,61 +69,65 @@ mainline GCC, not in any particular release.
For each entry, we give the section number of the standard, when
applicable. This list is probably incomplet and inkorrekt.
</p><p>
- <span class="emphasis"><em>[1.9]/11 #3</em></span> If <code
class="code">isatty(3)</code> is true, then
- interactive stream support is implied.
+ <span class="emphasis"><em>1.9 [intro.execution]/11 #3</em></span> If
<code class="code">isatty(3)</code>
+ is true, then interactive stream support is implied.
</p><p>
- <span class="emphasis"><em>[17.4.4.5]</em></span> Non-reentrant functions
are probably best
- discussed in the various sections on multithreading (see above).
- </p><p><span class="emphasis"><em>[18.1]/4</em></span> The type of <code
class="code">NULL</code> is described
- under <a class="link" href="support.html#std.support.types.null"
title="NULL">Support</a>.
- </p><p><span class="emphasis"><em>[18.3]/8</em></span> Even though it's
listed in the library
- sections, libstdc++ has zero control over what the cleanup code hands
- back to the runtime loader. Talk to the compiler people. :-)
- </p><p><span class="emphasis"><em>[18.4.2.1]/5</em></span> (bad_alloc),
- <span class="emphasis"><em>[18.5.2]/5</em></span> (bad_cast),
- <span class="emphasis"><em>[18.5.3]/5</em></span> (bad_typeid),
- <span class="emphasis"><em>[18.6.1]/8</em></span> (exception),
- <span class="emphasis"><em>[18.6.2.1]/5</em></span> (bad_exception):
The <code class="code">what()</code>
- member function of class <code class="code">std::exception</code>, and
these other
- classes publicly derived from it, returns the name of the
+ <span class="emphasis"><em>17.4.4.5 [lib.reentrancy]</em></span>
Non-reentrant functions are
+ probably best discussed in the various sections on multithreading (see
above).
+ </p><p><span class="emphasis"><em>18.1 [lib.support.types]/4</em></span>
The type of
+ <code class="code">NULL</code> is described under
+ <a class="link" href="support.html#std.support.types.null"
title="NULL">Support</a>.
+ </p><p><span class="emphasis"><em>18.3
[lib.support.start.term]/8</em></span> Even though it's
+ listed in the library sections, libstdc++ has zero control over what the
+ cleanup code hands back to the runtime loader. Talk to the compiler
people.
+ :-)
+ </p><p><span class="emphasis"><em>18.4.2.1 [lib.bad.alloc]/5</em></span>
(bad_alloc),
+ <span class="emphasis"><em>18.5.2 [lib.bad.cast]/5</em></span>
(bad_cast),
+ <span class="emphasis"><em>18.5.3 [lib.bad.typeid]/5</em></span>
(bad_typeid),
+ <span class="emphasis"><em>18.6.1 [lib.exception]/8</em></span>
(exception),
+ <span class="emphasis"><em>18.6.2.1 [lib.bad.exception]/5</em></span>
(bad_exception):
+ The <code class="code">what()</code> member function of class <code
class="code">std::exception</code>,
+ and these other classes publicly derived from it, returns the name of the
class, e.g. <code class="literal">"std::bad_alloc"</code>.
- </p><p><span class="emphasis"><em>[18.5.1]/7</em></span> The return value of
+ </p><p><span class="emphasis"><em>18.5.1 [lib.type.info]/7</em></span> The
return value of
<code class="code">std::type_info::name()</code> is the mangled type
name.
You will need to call <code class="code">c++filt</code> and pass the
names as
command-line parameters to demangle them, or call a
<a class="link" href="ext_demangling.html" title="Chapter 28.
Demangling">runtime demangler function</a>.
- </p><p><span class="emphasis"><em>[20.1.5]/5</em></span> <span
class="emphasis"><em>"Implementors are encouraged to
- supply libraries that can accept allocators that encapsulate more
- general memory models and that support non-equal instances. In such
- 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."</em></span> 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.
- </p><p><span class="emphasis"><em>[21.1.3.1]/3,4</em></span>,
- <span class="emphasis"><em>[21.1.3.2]/2</em></span>,
- <span class="emphasis"><em>[21.3]/6 basic_string::iterator,
basic_string::const_iterator</em></span>,
- <span class="emphasis"><em>[23.*]'s foo::iterator</em></span>,
- <span class="emphasis"><em>[27.*]'s foo::*_type</em></span>,
+ </p><p><span class="emphasis"><em>20.1.5
[lib.allocator.requirements]/5</em></span>
+ <span class="emphasis"><em>"Implementors are encouraged to supply
libraries that can
+ accept allocators that encapsulate more general memory models and that
+ support non-equal instances. In such 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."</em></span>
+ 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.
+ </p><p><span class="emphasis"><em>21.1.3.1
[lib.char.traits.specializations.char]/3,4</em></span>,
+ <span class="emphasis"><em>21.1.3.2
[lib.char.traits.specializations.wchar.t]/2</em></span>,
+ <span class="emphasis"><em>21.3 [lib.basic.string]/6
basic_string::iterator,
+ basic_string::const_iterator</em></span>,
+ <span class="emphasis"><em>23.* [lib.containers]'s
foo::iterator</em></span>,
+ <span class="emphasis"><em>27.* [lib.input.output]'s
foo::*_type</em></span>,
<span class="emphasis"><em>others...</em></span>
Nope, these types are called implementation-defined because you
shouldn't be taking advantage of their underlying types. Listing them
here would defeat the purpose. :-)
- </p><p><span class="emphasis"><em>[21.1.3.1]/5</em></span> I don't really
know about
- the <span class="type">mbstate_t</span> stuff... see
+ </p><p><span class="emphasis"><em>21.1.3.1
[lib.char.traits.specializations.char]/5</em></span>
+ I don't really know about the <span class="type">mbstate_t</span>
stuff... see
the <a class="link" href="facets.html#std.localization.facet.codecvt"
title="codecvt"><code class="code">codecvt</code>
notes</a> for what does exist.
- </p><p><span class="emphasis"><em>[22.*]</em></span> Anything and
everything we have on locale
- implementation will be described under
+ </p><p><span class="emphasis"><em>22.* [lib.localization]</em></span>
Anything and everything
+ we have on locale implementation will be described under
<a class="link" href="localization.html#std.localization.locales.locale"
title="locale">Localization</a>.
- </p><p><span class="emphasis"><em>[23.*]</em></span> All of the containers
in this clause
- define <span class="type">size_type</span> as <span
class="type">std::size_t</span> and
+ </p><p><span class="emphasis"><em>23.* [lib.containers]</em></span> All of
the containers in
+ this clause define <span class="type">size_type</span> as <span
class="type">std::size_t</span> and
<span class="type">difference_type</span> as <span
class="type">std::ptrdiff_t</span>.
- </p><p><span class="emphasis"><em>[26.2.8]/9</em></span> I have no idea what
- <code class="code">complex<T></code>'s <code
class="code">pow(0,0)</code> returns.
- </p><p><span class="emphasis"><em>[27.4.2.4]/2</em></span> Calling
+ </p><p><span class="emphasis"><em>26.2.8
[lib.complex.transcendentals/9</em></span> I have no
+ idea what <code class="code">complex<T></code>'s <code
class="code">pow(0,0)</code> returns.
+ </p><p><span class="emphasis"><em>27.4.2.4
[lib.ios.members.static/2</em></span> Calling
<code class="code">std::ios_base::sync_with_stdio</code> after I/O has
already been
performed on the standard stream objects will
flush the buffers, and
@@ -131,16 +135,17 @@ mainline GCC, not in any particular release.
the previously-written I/O is destroyed in this process depends mostly
on the <code class="code">--enable-libio</code> choice: for stdio, if
the written
data is already in the stdio buffer, the data may be completely safe!
- </p><p><span class="emphasis"><em>[27.6.1.1.2]</em></span>,
- <span class="emphasis"><em>[27.6.2.3]</em></span> 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><span class="emphasis"><em>[27.7.1.3]/16</em></span>,
- <span class="emphasis"><em>[27.8.1.4]/10</em></span>
+ </p><p><span class="emphasis"><em>27.6.1.1.2
[lib.istream::sentry]</em></span>,
+ <span class="emphasis"><em>27.6.2.3 [lib.ostream::sentry]</em></span>
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><span class="emphasis"><em>27.7.1.3
[lib.stringbuf.virtuals]/16</em></span>,
+ <span class="emphasis"><em>27.8.1.4 [lib.filebuf.virtuals]/10</em></span>
The effects of <code class="code">pubsetbuf/setbuf</code> are described
in the
<a class="link" href="io.html" title="Chapter 13. Input and
Output">Input and Output</a> chapter.
- </p><p><span class="emphasis"><em>[27.8.1.4]/16</em></span> Calling <code
class="code">fstream::sync</code> when
- a get area exists will... whatever <code class="code">fflush()</code>
does, I think.
+ </p><p><span class="emphasis"><em>27.8.1.4
[lib.filebuf.virtuals]/16</em></span> Calling
+ <code class="code">fstream::sync</code> when a get area exists will...
whatever
+ <code class="code">fflush()</code> does, I think.
</p></div></div><div class="section"><div class="titlepage"><div><div><h3
class="title"><a id="status.iso.2011"></a>C++ 2011</h3></div></div></div><p>
<a id="status.iso.200x"></a>
This table is based on the table of contents of ISO/IEC
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 6b84e7c36e25..3cabf742f77f 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -1063,77 +1063,81 @@ mainline GCC, not in any particular release.
applicable. This list is probably incomplet and inkorrekt.
</para>
<para>
- <emphasis>[1.9]/11 #3</emphasis> If <code>isatty(3)</code> is true, then
- interactive stream support is implied.
+ <emphasis>1.9 [intro.execution]/11 #3</emphasis> If <code>isatty(3)</code>
+ is true, then interactive stream support is implied.
</para>
<para>
- <emphasis>[17.4.4.5]</emphasis> Non-reentrant functions are probably best
- discussed in the various sections on multithreading (see above).
+ <emphasis>17.4.4.5 [lib.reentrancy]</emphasis> Non-reentrant functions are
+ probably best discussed in the various sections on multithreading (see
above).
</para>
<!-- [17.4.4.8]/3 says any function that doesn't have an exception-spec
can throw whatever we want; see also its footnote. Let's list those
in the sections where the function itself occurs.
-->
- <para><emphasis>[18.1]/4</emphasis> The type of <code>NULL</code> is
described
- under <link linkend="std.support.types.null">Support</link>.
+ <para><emphasis>18.1 [lib.support.types]/4</emphasis> The type of
+ <code>NULL</code> is described 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
- back to the runtime loader. Talk to the compiler people. :-)
+ <para><emphasis>18.3 [lib.support.start.term]/8</emphasis> Even though it's
+ listed in the library sections, libstdc++ has zero control over what the
+ cleanup code hands back to the runtime loader. Talk to the compiler
people.
+ :-)
</para>
- <para><emphasis>[18.4.2.1]/5</emphasis> (bad_alloc),
- <emphasis>[18.5.2]/5</emphasis> (bad_cast),
- <emphasis>[18.5.3]/5</emphasis> (bad_typeid),
- <emphasis>[18.6.1]/8</emphasis> (exception),
- <emphasis>[18.6.2.1]/5</emphasis> (bad_exception): The
<code>what()</code>
- member function of class <code>std::exception</code>, and these other
- classes publicly derived from it, returns the name of the
+ <para><emphasis>18.4.2.1 [lib.bad.alloc]/5</emphasis> (bad_alloc),
+ <emphasis>18.5.2 [lib.bad.cast]/5</emphasis> (bad_cast),
+ <emphasis>18.5.3 [lib.bad.typeid]/5</emphasis> (bad_typeid),
+ <emphasis>18.6.1 [lib.exception]/8</emphasis> (exception),
+ <emphasis>18.6.2.1 [lib.bad.exception]/5</emphasis> (bad_exception):
+ The <code>what()</code> member function of class
<code>std::exception</code>,
+ and these other classes publicly derived from it, returns the name of the
class, e.g. <literal>"std::bad_alloc"</literal>.
</para>
- <para><emphasis>[18.5.1]/7</emphasis> The return value of
+ <para><emphasis>18.5.1 [lib.type.info]/7</emphasis> The return value of
<code>std::type_info::name()</code> is the mangled type name.
You will need to call <code>c++filt</code> and pass the names as
command-line parameters to demangle them, or call a
<link linkend="manual.ext.demangle">runtime demangler function</link>.
</para>
- <para><emphasis>[20.1.5]/5</emphasis> <emphasis>"Implementors are
encouraged to
- supply libraries that can accept allocators that encapsulate more
- general memory models and that support non-equal instances. In such
- 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> 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><emphasis>20.1.5 [lib.allocator.requirements]/5</emphasis>
+ <emphasis>"Implementors are encouraged to supply libraries that can
+ accept allocators that encapsulate more general memory models and that
+ support non-equal instances. In such 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>
+ 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>,
- <emphasis>[21.3]/6 basic_string::iterator,
basic_string::const_iterator</emphasis>,
- <emphasis>[23.*]'s foo::iterator</emphasis>,
- <emphasis>[27.*]'s foo::*_type</emphasis>,
+ <para><emphasis>21.1.3.1
[lib.char.traits.specializations.char]/3,4</emphasis>,
+ <emphasis>21.1.3.2
[lib.char.traits.specializations.wchar.t]/2</emphasis>,
+ <emphasis>21.3 [lib.basic.string]/6 basic_string::iterator,
+ basic_string::const_iterator</emphasis>,
+ <emphasis>23.* [lib.containers]'s foo::iterator</emphasis>,
+ <emphasis>27.* [lib.input.output]'s foo::*_type</emphasis>,
<emphasis>others...</emphasis>
Nope, these types are called implementation-defined because you
shouldn't be taking advantage of their underlying types. Listing them
here would defeat the purpose. :-)
</para>
- <para><emphasis>[21.1.3.1]/5</emphasis> I don't really know about
- the <type>mbstate_t</type> stuff... see
+ <para><emphasis>21.1.3.1 [lib.char.traits.specializations.char]/5</emphasis>
+ I don't really know about 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 under
+ <para><emphasis>22.* [lib.localization]</emphasis> Anything and everything
+ we have on locale implementation will be described under
<link linkend="std.localization.locales.locale">Localization</link>.
</para>
- <para><emphasis>[23.*]</emphasis> All of the containers in this clause
- define <type>size_type</type> as <type>std::size_t</type> and
+ <para><emphasis>23.* [lib.containers]</emphasis> All of the containers in
+ this clause define <type>size_type</type> as <type>std::size_t</type> and
<type>difference_type</type> as <type>std::ptrdiff_t</type>.
</para>
- <para><emphasis>[26.2.8]/9</emphasis> I have no idea what
- <code>complex<T></code>'s <code>pow(0,0)</code> returns.
+ <para><emphasis>26.2.8 [lib.complex.transcendentals/9</emphasis> I have no
+ idea what <code>complex<T></code>'s <code>pow(0,0)</code> returns.
</para>
- <para><emphasis>[27.4.2.4]/2</emphasis> Calling
+ <para><emphasis>27.4.2.4 [lib.ios.members.static/2</emphasis> Calling
<code>std::ios_base::sync_with_stdio</code> after I/O has already been
performed on the standard stream objects will
flush the buffers, and <!-- this line might go away -->
@@ -1142,18 +1146,19 @@ mainline GCC, not in any particular release.
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
- additional work than the minimum required. We are not currently taking
- advantage of this yet.
+ <para><emphasis>27.6.1.1.2 [lib.istream::sentry]</emphasis>,
+ <emphasis>27.6.2.3 [lib.ostream::sentry]</emphasis> The I/O sentry ctor
+ and dtor can perform additional work than the minimum required. We are
+ not currently taking advantage of this yet.
</para>
- <para><emphasis>[27.7.1.3]/16</emphasis>,
- <emphasis>[27.8.1.4]/10</emphasis>
+ <para><emphasis>27.7.1.3 [lib.stringbuf.virtuals]/16</emphasis>,
+ <emphasis>27.8.1.4 [lib.filebuf.virtuals]/10</emphasis>
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.
+ <para><emphasis>27.8.1.4 [lib.filebuf.virtuals]/16</emphasis> Calling
+ <code>fstream::sync</code> when a get area exists will... whatever
+ <code>fflush()</code> does, I think.
</para>
</section>
