]> git.ipfire.org Git - thirdparty/gcc.git/commitdiff
libstdc++: Fix incorrect links to archived SGI STL docs
authorJonathan Wakely <jwakely@redhat.com>
Tue, 20 May 2025 09:53:41 +0000 (10:53 +0100)
committerJonathan Wakely <redi@gcc.gnu.org>
Wed, 11 Jun 2025 10:18:25 +0000 (11:18 +0100)
In r8-7777-g25949ee33201f2 I updated some URLs to point to copies of the
SGI STL docs in the Wayback Machine, because the original pags were no
longer hosted on sgi.com. However, I incorrectly assumed that if one
archived page was at https://web.archive.org/web/20171225062613/... then
all the other pages would be too. Apparently that's not how the Wayback
Machine works, and each page is archived on a different date. That meant
that some of our links were redirecting to archived copies of the
announcement that the SGI STL docs have gone away.

This fixes each URL to refer to a correctly archived copy of the
original docs.

libstdc++-v3/ChangeLog:

* doc/xml/faq.xml: Update URL for archived SGI STL docs.
* doc/xml/manual/containers.xml: Likewise.
* doc/xml/manual/extensions.xml: Likewise.
* doc/xml/manual/using.xml: Likewise.
* doc/xml/manual/utilities.xml: Likewise.
* doc/html/*: Regenerate.

(cherry picked from commit 501e6e786652748ff0ad9a322f74b9b47970031f)

libstdc++-v3/doc/html/faq.html
libstdc++-v3/doc/html/manual/containers.html
libstdc++-v3/doc/html/manual/ext_numerics.html
libstdc++-v3/doc/html/manual/ext_sgi.html
libstdc++-v3/doc/html/manual/using_concurrency.html
libstdc++-v3/doc/html/manual/utilities.html
libstdc++-v3/doc/xml/faq.xml
libstdc++-v3/doc/xml/manual/containers.xml
libstdc++-v3/doc/xml/manual/extensions.xml
libstdc++-v3/doc/xml/manual/using.xml
libstdc++-v3/doc/xml/manual/utilities.xml

index f49b84c4c33a37afc3797cf271543f6edcfe8b21..8c103e2c142c202db1dd9ca61a7d0ea734694cce 100644 (file)
     Libstdc++-v3 incorporates a lot of code from
     <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/" target="_top">the SGI STL</a>
     (the final merge was from
-    <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/whats_new.html" target="_top">release 3.3</a>).
+    <a class="link" href="https://web.archive.org/web/20171206110416/http://www.sgi.com/tech/stl/whats_new.html" target="_top">release 3.3</a>).
     The code in libstdc++ contains many fixes and changes compared to the
     original SGI code.
     </p><p>
index 7035a949074d9411cda55dd4851826e2ba6e5313..dcd609a6000d909b838996d24246b3f50cd0c10e 100644 (file)
@@ -11,7 +11,7 @@
      Yes it is, at least using the <a class="link" href="using_dual_abi.html" title="Dual ABI">old
      ABI</a>, and that's okay.  This is a decision that we preserved
      when we imported SGI's STL implementation.  The following is
-     quoted from <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/FAQ.html" target="_top">their FAQ</a>:
+     quoted from <a class="link" href="https://web.archive.org/web/20161222192301/http://www.sgi.com/tech/stl/FAQ.html" target="_top">their FAQ</a>:
    </p><div class="blockquote"><blockquote class="blockquote"><p>
        The size() member function, for list and slist, takes time
        proportional to the number of elements in the list.  This was a
index 9b864e1dcf4a1656df0f048895abb963c7885ba4..c3a5623d1752b2ba1441989e3f115876022cedc9 100644 (file)
@@ -14,7 +14,7 @@
    The operation functor must be associative.
 </p><p>The <code class="code">iota</code> function wins the award for Extension With the
    Coolest Name (the name comes from Ken Iverson's APL language.)  As
-   described in the <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/iota.html" target="_top">SGI
+   described in the <a class="link" href="https://web.archive.org/web/20170201044840/http://www.sgi.com/tech/stl/iota.html" target="_top">SGI
    documentation</a>, it "assigns sequentially increasing values to a range.
    That is, it assigns <code class="code">value</code> to <code class="code">*first</code>,
    <code class="code">value + 1</code> to<code class="code"> *(first + 1)</code> and so on."
index ae2062954f4fbbb099bb4e4e62f6bcb9da683c38..2310857804b30902946dcd08298e51709e16cb77 100644 (file)
       and sets.
    </p><p>Each of the associative containers map, multimap, set, and multiset
       have a counterpart which uses a
-      <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/HashFunction.html" target="_top">hashing
+      <a class="link" href="https://web.archive.org/web/20171230172024/http://www.sgi.com/tech/stl/HashFunction.html" target="_top">hashing
       function</a> to do the arranging, instead of a strict weak ordering
       function.  The classes take as one of their template parameters a
       function object that will return the hash value; by default, an
       instantiation of
-      <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/hash.html" target="_top">hash</a>.
+      <a class="link" href="https://web.archive.org/web/20171230172200/http://www.sgi.com/tech/stl/hash.html" target="_top">hash</a>.
       You should specialize this functor for your class, or define your own,
       before trying to use one of the hashing classes.
    </p><p>The hashing classes support all the usual associative container
index f99cca414ec872cb991a2825b094c45d61f9ef26..a75adbf0f2238bfa294113df0d79d708dbf71a31 100644 (file)
@@ -40,7 +40,7 @@ The standard places requirements on the library to ensure that no data
 races are caused by the library itself or by programs which use the
 library correctly (as described below).
 The C++11 memory model and library requirements are a more formal version
-of the <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI STL</a> definition of thread safety, which the library used
+of the <a class="link" href="https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI STL</a> definition of thread safety, which the library used
 prior to the 2011 standard.
 </p><p>The library strives to be thread-safe when all of the following
         conditions are met:
@@ -243,10 +243,10 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
       threaded and non-threaded code), see Chapter 17.
    </p><p>Two excellent pages to read when working with the Standard C++
       containers and threads are
-      <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI's
-      https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html</a> and
-      <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/Allocators.html" target="_top">SGI's
-      https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/Allocators.html</a>.
+      <a class="link" href="https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI's
+      https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html</a> and
+      <a class="link" href="https://web.archive.org/web/20171108142526/http://www.sgi.com/tech/stl/Allocators.html" target="_top">SGI's
+      https://web.archive.org/web/20171108142526/http://www.sgi.com/tech/stl/Allocators.html</a>.
    </p><p><span class="emphasis"><em>However, please ignore all discussions about the user-level
       configuration of the lock implementation inside the STL
       container-memory allocator on those pages.  For the sake of this
index 15c9a9d170aec8009f582f84d1bf489f564b865a..1216b72ad3e8fbb3f0c2286638ef9d0d955c40f3 100644 (file)
@@ -11,6 +11,6 @@
       get slightly the wrong idea.  In the interest of not reinventing
       the wheel, we will refer you to the introduction to the functor
       concept written by SGI as part of their STL, in
-      <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/functors.html" target="_top">their
-      https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/functors.html</a>.
+      <a class="link" href="https://web.archive.org/web/20171209002754/http://www.sgi.com/tech/stl/functors.html" target="_top">their
+      https://web.archive.org/web/20171209002754/http://www.sgi.com/tech/stl/functors.html</a>.
    </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="concept_checking.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="std_contents.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="pairs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Concept Checking </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Pairs</td></tr></table></div></body></html>
\ No newline at end of file
index 9ae4966ecea1551d7c94970fa1a479c551a52983..729a11f088d0a13b4c8f0b8c1799b2684b51b4ec 100644 (file)
     Libstdc++-v3 incorporates a lot of code from
     <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/">the SGI STL</link>
     (the final merge was from
-    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/whats_new.html">release 3.3</link>).
+    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171206110416/http://www.sgi.com/tech/stl/whats_new.html">release 3.3</link>).
     The code in libstdc++ contains many fixes and changes compared to the
     original SGI code.
     </para>
index e5810fa5f314c43acc65da158da706e871835210..1f2efcfb8a2cb4461f1e6ff4ec52eb7f562a1411 100644 (file)
@@ -28,7 +28,7 @@
      Yes it is, at least using the <link linkend="manual.intro.using.abi">old
      ABI</link>, and that's okay.  This is a decision that we preserved
      when we imported SGI's STL implementation.  The following is
-     quoted from <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/FAQ.html">their FAQ</link>:
+     quoted from <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20161222192301/http://www.sgi.com/tech/stl/FAQ.html">their FAQ</link>:
    </para>
    <blockquote>
      <para>
index 196b55d83479196bd5361037482b480cdd3c5ce4..8156d4f1312efd39d104c897a0215380be9c5864 100644 (file)
@@ -221,12 +221,12 @@ extensions, be aware of two things:
    </para>
    <para>Each of the associative containers map, multimap, set, and multiset
       have a counterpart which uses a
-      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/HashFunction.html">hashing
+      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171230172024/http://www.sgi.com/tech/stl/HashFunction.html">hashing
       function</link> to do the arranging, instead of a strict weak ordering
       function.  The classes take as one of their template parameters a
       function object that will return the hash value; by default, an
       instantiation of
-      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/hash.html">hash</link>.
+      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171230172200/http://www.sgi.com/tech/stl/hash.html">hash</link>.
       You should specialize this functor for your class, or define your own,
       before trying to use one of the hashing classes.
    </para>
@@ -388,7 +388,7 @@ get_temporary_buffer(5, (int*)0);
 </para>
 <para>The <code>iota</code> function wins the award for Extension With the
    Coolest Name (the name comes from Ken Iverson's APL language.)  As
-   described in the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/iota.html">SGI
+   described in the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20170201044840/http://www.sgi.com/tech/stl/iota.html">SGI
    documentation</link>, it "assigns sequentially increasing values to a range.
    That is, it assigns <code>value</code> to <code>*first</code>,
    <code>value + 1</code> to<code> *(first + 1)</code> and so on."
index 04aff0c8b8dfc8aa276dc5476dd4bd97f2fe703c..354f2271b2f1250e360f824f977fa4677c406b55 100644 (file)
@@ -1690,7 +1690,7 @@ The standard places requirements on the library to ensure that no data
 races are caused by the library itself or by programs which use the
 library correctly (as described below).
 The C++11 memory model and library requirements are a more formal version
-of the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html">SGI STL</link> definition of thread safety, which the library used
+of the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html">SGI STL</link> definition of thread safety, which the library used
 prior to the 2011 standard.
 </para>
 
@@ -1975,10 +1975,10 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
    </para>
    <para>Two excellent pages to read when working with the Standard C++
       containers and threads are
-      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html">SGI's
-      https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html</link> and
-      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/Allocators.html">SGI's
-      https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/Allocators.html</link>.
+      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html">SGI's
+      https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html</link> and
+      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171108142526/http://www.sgi.com/tech/stl/Allocators.html">SGI's
+      https://web.archive.org/web/20171108142526/http://www.sgi.com/tech/stl/Allocators.html</link>.
    </para>
    <para><emphasis>However, please ignore all discussions about the user-level
       configuration of the lock implementation inside the STL
index e155c8c39435a75a94be529a0da634475306df5a..c2e013e341659faed61ed1519f245aaa263c1cbf 100644 (file)
@@ -22,8 +22,8 @@
       get slightly the wrong idea.  In the interest of not reinventing
       the wheel, we will refer you to the introduction to the functor
       concept written by SGI as part of their STL, in
-      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/functors.html">their
-      https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/functors.html</link>.
+      <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171209002754/http://www.sgi.com/tech/stl/functors.html">their
+      https://web.archive.org/web/20171209002754/http://www.sgi.com/tech/stl/functors.html</link>.
    </para>
 </section>