mc-tech-docs.xml:

- fixed link to comply with house-style
mc-manual.xml:
- rm'd unhelpful sentence + it's footnote
quick-start-guide.xml:
- fixed up some section ids + xreflabels
  so we don't get cool filenames like 'bk01s02.html'.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3898

diff --git a/docs/xml/quick-start-guide.xml b/docs/xml/quick-start-guide.xml
index 4c685161ede5bb800ae07f3ad82b4c0ec4698e5b..b40952bc1ecae7878e932b97245511a4082fcf48 100644 (file)
--- a/docs/xml/quick-start-guide.xml
+++ b/docs/xml/quick-start-guide.xml
@@ -34,14 +34,16 @@ memory errors in your program with Memcheck.  Note that this guide applies
 to Valgrind version 2.4.0;  some of the information is not quite right for
 earlier versions.</para>
 
-<sect1>
+<sect1 id="quick-start.prepare" 
+       xreflabel="Preparing your program">
 <title>Preparing your program</title>
 <para>Compile your program with <computeroutput>-g</computeroutput> to include
 debugging information so that Memcheck's error messages include exact line
 numbers.</para>
 </sect1>
 
-<sect1>
+<sect1 id="quick-start.mcrun" 
+       xreflabel="Running your program under Memcheck">
 <title>Running your program under Memcheck</title>
 <para>If you normally run your program like this:
 
@@ -64,7 +66,8 @@ and use a lot more memory.  Memcheck will issue messages about memory errors
 and leaks that it detects.</para>
 </sect1>
 
-<sect1>
+<sect1 id="quick-start.interpret" 
+       xreflabel="Interpreting Memcheck's output">
 <title>Interpreting Memcheck's output</title>
 <para>Here's an example C program with a memory error and a memory leak.
 
@@ -170,7 +173,7 @@ If you don't understand an error message, please consult
 examples of all the error messages Memcheck produces.</para>
 </sect1>
 
-<sect1>
+<sect1 id="quick-start.caveats" xreflabel="Caveats">
 <title>Caveats</title>
 <para>Memcheck is not perfect;  it occasionally produces false positives,
 and there are mechanisms for suppressing these (see
@@ -184,7 +187,7 @@ example, it can't detect if you overrun the bounds of an array that is
 allocated statically or on the stack.</para>
 </sect1>
 
-<sect1>
+<sect1 id="quick-start.info" xreflabel="More Information">
 <title>More information</title>
 <para>Please consult the <xref linkend="FAQ"/> and the
 <xref linkend="manual"/>, which have much more information.  Note that the

diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml
index c7fdaa5718add4f60a3a7d2f6a659a38a0c3dc82..8c963d0f4968f127b3ab22e90c38ce9de9d7107d 100644 (file)
--- a/memcheck/docs/mc-manual.xml
+++ b/memcheck/docs/mc-manual.xml
@@ -396,16 +396,7 @@ pointer-to-member to the destructor of the array's content just
 before the pointer actually returned.  This implies a
 variable-sized overhead in what's returned by
 <computeroutput>new</computeroutput> or
-<computeroutput>new[]</computeroutput>.  It rather surprising how
-compilers
-<footnote>
-  <para>[Ed: runtime-support libraries ?]</para>
-</footnote>
-are robust to mismatch in <computeroutput>new</computeroutput> /
-<computeroutput>delete</computeroutput>
-<computeroutput>new[]</computeroutput> /
-<computeroutput>delete[]</computeroutput>.</para>
-
+<computeroutput>new[]</computeroutput>.
 </sect2>
 
 

diff --git a/memcheck/docs/mc-tech-docs.xml b/memcheck/docs/mc-tech-docs.xml
index be1b852dd0f1381cd4c9e210480d5b0c0532c6c0..28193300cf03b560d97dfc3e6fb2eb64a82c525b 100644 (file)
--- a/memcheck/docs/mc-tech-docs.xml
+++ b/memcheck/docs/mc-tech-docs.xml
@@ -1534,7 +1534,7 @@ different.</para>
 
 
 
-<sect2 id="mc-manual.trans" xreflabel="Translation into UCode">
+<sect2 id="mc-tech-docs.trans" xreflabel="Translation into UCode">
 <title>Translation into UCode</title>
 
 <para><computeroutput>VG_(disBB)</computeroutput> allocates a new