diff mbox series

[committed] libstdc++: Update/streamline Valgrind references

Message ID 20200601150649.35A0333E10@hamza.pair.com
State New
Headers show
Series [committed] libstdc++: Update/streamline Valgrind references | expand

Commit Message

Gerald Pfeifer June 1, 2020, 3:06 p.m. UTC 
Like many sites over the last year(s) valgrind.org has now moved to 
https.  While there, replace the second of two links in the same vicinity 
by a purely textual reference -- easier to maintain, and in particular
also better from a user experience perspective.

Gerald

	* doc/xml/faq.xml: Adjust Valgrind reference and remove another.
	* doc/html/faq.html: Regenerate.
---
 libstdc++-v3/doc/html/faq.html | 4 ++--
 libstdc++-v3/doc/xml/faq.xml   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

Comments

Jonathan Wakely June 1, 2020, 5:33 p.m. UTC | #1 
On 01/06/20 17:06 +0200, Gerald Pfeifer wrote:
>Like many sites over the last year(s) valgrind.org has now moved to
>https.  While there, replace the second of two links in the same vicinity
>by a purely textual reference -- easier to maintain, and in particular
>also better from a user experience perspective.

Thanks.

I've also committed a couple more doc improvements, as attached.
diff mbox series

Patch

diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html
index 18407225d7a..967e5f5f348 100644
--- a/libstdc++-v3/doc/html/faq.html
+++ b/libstdc++-v3/doc/html/faq.html
@@ -700,7 +700,7 @@ 
     of a few dozen kilobytes on startup. This pool is used to ensure it's
     possible to throw exceptions (such as <code class="classname">bad_alloc</code>)
     even when <code class="code">malloc</code> is unable to allocate any more memory.
-    With some versions of <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>
+    With some versions of <a class="link" href="https://valgrind.org" target="_top"><span class="command"><strong>valgrind</strong></span></a>
     this pool will be shown as "still reachable" when the process exits, e.g.
     <code class="code">still reachable: 72,704 bytes in 1 blocks</code>.
     This memory is not a leak, because it's still in use by libstdc++,
@@ -710,7 +710,7 @@ 
     </p><p>
     In the past, a few people reported that the standard containers appear
     to leak memory when tested with memory checkers such as
-    <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>.
+    <span class="command"><strong>valgrind</strong></span>.
     Under some (non-default) configurations the library's allocators keep
     free memory in a
     pool for later reuse, rather than deallocating it with <code class="code">delete</code>
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index cf8684e1cea..e419d3c22a0 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -993,7 +993,7 @@ 
     of a few dozen kilobytes on startup. This pool is used to ensure it's
     possible to throw exceptions (such as <classname>bad_alloc</classname>)
     even when <code>malloc</code> is unable to allocate any more memory.
-    With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>
+    With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://valgrind.org"><command>valgrind</command></link>
     this pool will be shown as "still reachable" when the process exits, e.g.
     <code>still reachable: 72,704 bytes in 1 blocks</code>.
     This memory is not a leak, because it's still in use by libstdc++,
@@ -1004,7 +1004,7 @@ 
     <para>
     In the past, a few people reported that the standard containers appear
     to leak memory when tested with memory checkers such as
-    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>.
+    <command>valgrind</command>.
     Under some (non-default) configurations the library's allocators keep
     free memory in a
     pool for later reuse, rather than deallocating it with <code>delete</code>