aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/doc/html
diff options
context:
space:
mode:
authorGerald Pfeifer <gerald@pfeifer.com>2020-06-01 17:03:51 +0200
committerGerald Pfeifer <gerald@pfeifer.com>2020-06-01 17:04:22 +0200
commite41b988cc5af34e9c1a3d37b717fbfcc52d7ff90 (patch)
tree3330771d4155bb0a944279ad55d72cacd8a8ed11 /libstdc++-v3/doc/html
parentff7da2b5d621d0aaf4a467344d0621eefd4aa78f (diff)
downloadgcc-e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90.zip
gcc-e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90.tar.gz
gcc-e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90.tar.bz2
libstdc++: Update/streamline Valgrind references
* doc/xml/faq.xml: Adjust Valgrind reference and remove another. * doc/html/faq.html: Regenerate.
Diffstat (limited to 'libstdc++-v3/doc/html')
-rw-r--r--libstdc++-v3/doc/html/faq.html4
1 files changed, 2 insertions, 2 deletions
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html
index 1840722..967e5f5 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>