Be consistent in the naming of sections describing command-line options.
Also, use "option" rather than "flag" where possible, for consistency.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10758 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index 8454f2e..9ee8ea3 100644
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -132,7 +132,7 @@
older glibc versions causes this crash.</para>
<para>Workaround for 1.1.X and later versions of Valgrind: use the
- <option>--run-libc-freeres=no</option> flag. You may then get space
+ <option>--run-libc-freeres=no</option> option. You may then get space
leak reports for glibc allocations (please don't report these to
the glibc people, since they are not real leaks), but at least the
program runs.</para>
@@ -424,7 +424,7 @@
<para>If you are tracing large trees of processes, it can be less
disruptive to have the output sent over the network. Give Valgrind
- the flag <option>--log-socket=127.0.0.1:12345</option> (if you want
+ the option <option>--log-socket=127.0.0.1:12345</option> (if you want
logging output sent to port <literal>12345</literal> on
<literal>localhost</literal>). You can use the valgrind-listener
program to listen on that port:</para>
@@ -557,7 +557,7 @@
<answer id="a-undeferrors">
<para>Prior to version 3.4.0, the answer was "we don't know how to do it
without huge performance penalties". As of 3.4.0, try using the
- <option>--track-origins=yes</option> flag. It will run slower than
+ <option>--track-origins=yes</option> option. It will run slower than
usual, but will give you extra information about the origin of
uninitialised values.</para>
diff --git a/docs/xml/manual-core-adv.xml b/docs/xml/manual-core-adv.xml
index bf02d07..d04a962 100644
--- a/docs/xml/manual-core-adv.xml
+++ b/docs/xml/manual-core-adv.xml
@@ -511,7 +511,7 @@
<para>Figuring out what's going on given the dynamic nature of wrapping
can be difficult. The
-<option>--trace-redir=yes</option> flag makes
+<option>--trace-redir=yes</option> option makes
this possible
by showing the complete state of the redirection subsystem after
every
@@ -550,7 +550,7 @@
time an active specification is used for the first time.</para>
<para>Hence for maximum debugging effectiveness you will need to use both
-flags.</para>
+options.</para>
<para>One final comment. The function-wrapping facility is closely
tied to Valgrind's ability to replace (redirect) specified
diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml
index 9104078..a3fa73c 100644
--- a/docs/xml/manual-core.xml
+++ b/docs/xml/manual-core.xml
@@ -7,10 +7,10 @@
<chapter id="manual-core" xreflabel="Valgrind's core">
<title>Using and understanding the Valgrind core</title>
-<para>This chapter describes the Valgrind core services, flags and
-behaviours. That means it is relevant regardless of what particular
-tool you are using. The information should be sufficient for you to
-make effective day-to-day use of Valgrind. Advanced topics related to
+<para>This chapter describes the Valgrind core services, command-line
+options and behaviours. That means it is relevant regardless of what
+particular tool you are using. The information should be sufficient for you
+to make effective day-to-day use of Valgrind. Advanced topics related to
the Valgrind core are described in <xref linkend="manual-core-adv"/>.
</para>
@@ -41,7 +41,7 @@
valgrind --tool=memcheck ls -l]]></programlisting>
<para>However, Memcheck is the default, so if you want to use it you can
-omit the <option>--tool</option> flag.</para>
+omit the <option>--tool</option> option.</para>
<para>Regardless of which tool is in use, Valgrind takes control of your
program before it starts. Debugging information is read from the
@@ -94,17 +94,17 @@
<para>First off, consider whether it might be beneficial to recompile
your application and supporting libraries with debugging info enabled
-(the <option>-g</option> flag). Without debugging info, the best
+(the <option>-g</option> option). Without debugging info, the best
Valgrind tools will be able to do is guess which function a particular
piece of code belongs to, which makes both error messages and profiling
output nearly useless. With <option>-g</option>, you'll get
messages which point directly to the relevant source code lines.</para>
-<para>Another flag you might like to consider, if you are working with
+<para>Another option you might like to consider, if you are working with
C++, is <option>-fno-inline</option>. That makes it easier to see the
function-call chain, which can help reduce confusion when navigating
around large C++ apps. For example, debugging
-OpenOffice.org with Memcheck is a bit easier when using this flag. You
+OpenOffice.org with Memcheck is a bit easier when using this option. You
don't have to do this, but doing so helps Valgrind produce more accurate
and less confusing error reports. Chances are you're set up like this
already, if you intended to debug your program with GNU GDB, or some
@@ -145,7 +145,7 @@
<filename>/bin/sh</filename>,
<filename>/usr/bin/perl</filename>, or whatever interpreter
you're using. This may not be what you want and can be confusing. You
-can force the issue by giving the flag
+can force the issue by giving the option
<option>--trace-children=yes</option>, but confusion is still
likely.</para>
@@ -171,7 +171,7 @@
<para>By default, Valgrind tools write only essential messages to the
commentary, so as to avoid flooding you with information of secondary
importance. If you want more information about what is happening,
-re-run, passing the <option>-v</option> flag to Valgrind. A second
+re-run, passing the <option>-v</option> option to Valgrind. A second
<option>-v</option> gives yet more detail.
</para>
@@ -235,7 +235,7 @@
connections in round brackets.</para>
<para><computeroutput>valgrind-listener</computeroutput> accepts two
- command-line flags:</para>
+ command-line options:</para>
<itemizedlist>
<listitem>
<para><option>-e</option> or <option>--exit-at-zero</option>:
@@ -335,8 +335,8 @@
if necessary.</para>
<para>To avoid this cutoff you can use the
-<option>--error-limit=no</option> flag. Then Valgrind will always show
-errors, regardless of how many there are. Use this flag carefully,
+<option>--error-limit=no</option> option. Then Valgrind will always show
+errors, regardless of how many there are. Use this option carefully,
since it may have a bad effect on performance.</para>
</sect1>
@@ -361,8 +361,8 @@
them.</para>
<formalpara><title>Note:</title> <para>By far the easiest way to add
-suppressions is to use the <option>--gen-suppressions=yes</option> flag
-described in <xref linkend="manual-core.flags"/>. This generates
+suppressions is to use the <option>--gen-suppressions=yes</option> option
+described in <xref linkend="manual-core.options"/>. This generates
suppressions automatically. For best results,
though, you may want to edit the output
of <option>--gen-suppressions=yes</option> by hand, in which
@@ -376,7 +376,7 @@
suppression mechanism is designed to allow precise yet flexible
specification of errors to suppress.</para>
-<para>If you use the <option>-v</option> flag, at the end of execution,
+<para>If you use the <option>-v</option> option, at the end of execution,
Valgrind prints out one line for each used suppression, giving its name
and the number of times it got used. Here's the suppressions used by a
run of <computeroutput>valgrind --tool=memcheck ls -l</computeroutput>:</para>
@@ -550,19 +550,19 @@
</sect1>
-<sect1 id="manual-core.flags"
- xreflabel="Command-line flags for the Valgrind core">
-<title>Command-line flags for the Valgrind core</title>
+<sect1 id="manual-core.options"
+ xreflabel="Core Command-line Options">
+<title>Core Command-line Options</title>
-<para>As mentioned above, Valgrind's core accepts a common set of flags.
-The tools also accept tool-specific flags, which are documented
+<para>As mentioned above, Valgrind's core accepts a common set of options.
+The tools also accept tool-specific options, which are documented
separately for each tool.</para>
<para>Valgrind's default settings succeed in giving reasonable behaviour
in most cases. We group the available options by rough categories.</para>
-<sect2 id="manual-core.toolopts" xreflabel="Tool-selection option">
-<title>Tool-selection option</title>
+<sect2 id="manual-core.toolopts" xreflabel="Tool-selection Option">
+<title>Tool-selection Option</title>
<para>The single most important option.</para>
@@ -637,7 +637,7 @@
of your program, such as: the shared objects loaded, the
suppressions used, the progress of the instrumentation and
execution engines, and warnings about unusual behaviour. Repeating
- the flag increases the verbosity level.</para>
+ the option increases the verbosity level.</para>
</listitem>
</varlistentry>
@@ -671,7 +671,7 @@
a <varname>fork</varname> call. This can make the output less
confusing (although more misleading) when dealing with processes
that create children. It is particularly useful in conjunction
- with <varname>--trace-children=</varname>. Use of this flag is also
+ with <varname>--trace-children=</varname>. Use of this option is also
strongly recommended if you are requesting XML output
(<varname>--xml=yes</varname>), since otherwise the XML from child and
parent may become mixed up, which usually makes it useless.
@@ -780,7 +780,7 @@
<sect2 id="manual-core.erropts" xreflabel="Error-related Options">
-<title>Error-related options</title>
+<title>Error-related Options</title>
<!-- start of xi:include in the manpage -->
<para id="error-related.opts.para">These options are used by all tools
@@ -815,7 +815,7 @@
<computeroutput>docs/internals/xml-output-protocol4.txt</computeroutput>
in the source tree for Valgrind 3.5.0 or later.</para>
- <para>The recommended flags for a GUI to pass, when requesting
+ <para>The recommended options for a GUI to pass, when requesting
XML output, are: <option>--xml=yes</option> to enable XML output,
<option>--xml-file</option> to send the XML output to a (presumably
GUI-selected) file, <option>--log-file</option> to send the plain
@@ -1079,7 +1079,7 @@
debugged.</para>
<para>Since <computeroutput><command></computeroutput> is likely
- to contain spaces, you will need to put this entire flag in
+ to contain spaces, you will need to put this entire option in
quotes to ensure it is correctly handled by the shell.</para>
</listitem>
</varlistentry>
@@ -1104,7 +1104,7 @@
<option><![CDATA[--dsymutil=no|yes [no] ]]></option>
</term>
<listitem>
- <para>This flag is only relevant when running Valgrind on
+ <para>This option is only relevant when running Valgrind on
Mac OS X.</para>
<para>Mac OS X uses a deferred debug information (debuginfo)
@@ -1184,7 +1184,7 @@
option allows you to change the threshold to a different
value.</para>
- <para>You should only consider use of this flag if Valgrind's
+ <para>You should only consider use of this option if Valgrind's
debug output directs you to do so. In that case it will tell you
the new threshold you should specify.</para>
@@ -1194,7 +1194,7 @@
support large numbers of threads each with a small stack, and also
because the error checking performed by Memcheck is more effective
for heap-allocated data than for stack-allocated data. If you
- have to use this flag, you may wish to consider rewriting your
+ have to use this option, you may wish to consider rewriting your
code to allocate on the heap rather than on the stack.</para>
</listitem>
</varlistentry>
@@ -1337,7 +1337,7 @@
and ppc64/Linux, Valgrind always provides complete, transparent
support for self-modifying code. It is only on platforms such as
x86/Linux, AMD64/Linux and x86/Darwin that you need to use this
- flag.</para>
+ option.</para>
</listitem>
</varlistentry>
@@ -1385,7 +1385,7 @@
<option><![CDATA[--run-libc-freeres=<yes|no> [default: yes] ]]></option>
</term>
<listitem>
- <para>This flag is only relevant when running Valgrind on Linux.</para>
+ <para>This option is only relevant when running Valgrind on Linux.</para>
<para>The GNU C library (<function>libc.so</function>), which is
used by all programs, may allocate memory for its own uses.
@@ -1405,7 +1405,7 @@
<para>Unfortunately, in some very old versions of glibc,
<function>__libc_freeres</function> is sufficiently buggy to cause
segmentation faults. This was particularly noticeable on Red Hat
- 7.1. So this flag is provided in order to inhibit the run of
+ 7.1. So this option is provided in order to inhibit the run of
<function>__libc_freeres</function>. If your program seems to run
fine on Valgrind, but segfaults at exit, you may find that
<option>--run-libc-freeres=no</option> fixes that, although at the
@@ -1480,8 +1480,8 @@
</sect2>
-<sect2 id="manual-core.debugopts" xreflabel="Debugging Valgrind Options">
-<title>Debugging Valgrind Options</title>
+<sect2 id="manual-core.debugopts" xreflabel="Debugging Options">
+<title>Debugging Options</title>
<!-- start of xi:include in the manpage -->
<para id="debug.opts.para">There are also some options for debugging
@@ -1493,8 +1493,8 @@
</sect2>
-<sect2 id="manual-core.defopts" xreflabel="Setting default options">
-<title>Setting default Options</title>
+<sect2 id="manual-core.defopts" xreflabel="Setting Default Options">
+<title>Setting Default Options</title>
<para>Note that Valgrind also reads options from three places:</para>
@@ -1639,7 +1639,7 @@
<para>This builds Valgrind with some special magic hacks which make
it possible to run it on a standard build of Valgrind (what the
developers call "self-hosting"). Ordinarily you should not use
- this flag as various kinds of safety checks are disabled.
+ this option as various kinds of safety checks are disabled.
</para>
</listitem>
@@ -1659,7 +1659,7 @@
platforms (amd64-linux, ppc64-linux), Valgrind is by default built
in such a way that both 32-bit and 64-bit executables can be run.
Sometimes this cleverness is a problem for a variety of reasons.
- These two flags allow for single-target builds in this situation.
+ These two options allow for single-target builds in this situation.
If you issue both, the configure script will complain. Note they
are ignored on 32-bit-only platforms (x86-linux, ppc32-linux).
</para>
@@ -1784,7 +1784,7 @@
code has changed, and work correctly. This is necessary to handle
the trampolines GCC uses to implemented nested functions. If you
regenerate code somewhere other than the stack, you will need to use
- the <option>--smc-check=all</option> flag, and Valgrind will run more
+ the <option>--smc-check=all</option> option, and Valgrind will run more
slowly than normal. Or you can add client requests that tell Valgrind
when your program has overwritten code.</para>
</listitem>
diff --git a/docs/xml/manual-intro.xml b/docs/xml/manual-intro.xml
index 1d1e42a..452effd 100644
--- a/docs/xml/manual-intro.xml
+++ b/docs/xml/manual-intro.xml
@@ -112,7 +112,7 @@
<title>How to navigate this manual</title>
<para>This manual's structure reflects the structure of Valgrind itself.
-First, we describe the Valgrind core, how to use it, and the flags
+First, we describe the Valgrind core, how to use it, and the options
it supports. Then, each tool has its own chapter in this manual. You
only need to read the documentation for the core and for the tool(s) you
actually use, although you may find it helpful to be at least a little
@@ -120,10 +120,10 @@
want to run the Memcheck tool and you might find the <xref
linkend="quick-start"/> useful.</para>
-<para>Be aware that the core understands some command line flags, and
-the tools have their own flags which they know about. This means
-there is no central place describing all the flags that are
-accepted -- you have to read the flags documentation both for
+<para>Be aware that the core understands some command line options, and
+the tools have their own options which they know about. This means
+there is no central place describing all the options that are
+accepted -- you have to read the options documentation both for
<xref linkend="manual-core"/> and for the tool you want to use.</para>