warning-options.html

自己收集的linux入门到学懂高级编程书集 包括linux程序设计第三版

the prior value shall be read only to determine the value to be
stored.".  If a program breaks these rules, the results on any
particular implementation are entirely unpredictable.

     <p>Examples of code with undefined behavior are <code>a = a++;</code>, <code>a[n]
= b[n++]</code> and <code>a[i++] = i;</code>.  Some more complicated cases are not
diagnosed by this option, and it may give an occasional false positive
result, but in general it has been found fairly effective at detecting
this sort of problem in programs.

     <p>The present implementation of this option only works for C programs.  A
future implementation may also work for C++ programs.

     <p>The C standard is worded confusingly, therefore there is some debate
over the precise meaning of the sequence point rules in subtle cases. 
Links to discussions of the problem, including proposed formal
definitions, may be found on our readings page, at
<a href="http://gcc.gnu.org/readings.html">http://gcc.gnu.org/readings.html</a>.

     <br><dt><code>-Wreturn-type</code>
     <dd>Warn whenever a function is defined with a return-type that defaults to
<code>int</code>.  Also warn about any <code>return</code> statement with no
return-value in a function whose return-type is not <code>void</code>.

     <p>For C++, a function without return type always produces a diagnostic
message, even when <code>-Wno-return-type</code> is specified.  The only
exceptions are <code>main</code> and functions defined in system headers.

     <br><dt><code>-Wswitch</code>
     <dd>Warn whenever a <code>switch</code> statement has an index of enumeral type
and lacks a <code>case</code> for one or more of the named codes of that
enumeration.  (The presence of a <code>default</code> label prevents this
warning.)  <code>case</code> labels outside the enumeration range also
provoke warnings when this option is used.

     <br><dt><code>-Wswitch-default</code>
     <dd>Warn whenever a <code>switch</code> statement does not have a <code>default</code>
case.

     <br><dt><code>-Wswitch-enum</code>
     <dd>Warn whenever a <code>switch</code> statement has an index of enumeral type
and lacks a <code>case</code> for one or more of the named codes of that
enumeration.  <code>case</code> labels outside the enumeration range also
provoke warnings when this option is used.

     <br><dt><code>-Wtrigraphs</code>
     <dd>Warn if any trigraphs are encountered that might change the meaning of
the program (trigraphs within comments are not warned about).

     <br><dt><code>-Wunused-function</code>
     <dd>Warn whenever a static function is declared but not defined or a
non\-inline static function is unused.

     <br><dt><code>-Wunused-label</code>
     <dd>Warn whenever a label is declared but not used.

     <p>To suppress this warning use the <code>unused</code> attribute
(see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>).

     <br><dt><code>-Wunused-parameter</code>
     <dd>Warn whenever a function parameter is unused aside from its declaration.

     <p>To suppress this warning use the <code>unused</code> attribute
(see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>).

     <br><dt><code>-Wunused-variable</code>
     <dd>Warn whenever a local variable or non-constant static variable is unused
aside from its declaration

     <p>To suppress this warning use the <code>unused</code> attribute
(see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>).

     <br><dt><code>-Wunused-value</code>
     <dd>Warn whenever a statement computes a result that is explicitly not used.

     <p>To suppress this warning cast the expression to <code>void</code>.

     <br><dt><code>-Wunused</code>
     <dd>All the above <code>-Wunused</code> options combined.

     <p>In order to get a warning about an unused function parameter, you must
either specify <code>-Wextra -Wunused</code> (note that <code>-Wall</code> implies
<code>-Wunused</code>), or separately specify <code>-Wunused-parameter</code>.

     <br><dt><code>-Wuninitialized</code>
     <dd>Warn if an automatic variable is used without first being initialized or
if a variable may be clobbered by a <code>setjmp</code> call.

     <p>These warnings are possible only in optimizing compilation,
because they require data flow information that is computed only
when optimizing.  If you don't specify <code>-O</code>, you simply won't
get these warnings.

     <p>If you want to warn about code which uses the uninitialized value of the
variable in its own initializer, use the <code>-Winit-self</code> option.

     <p>These warnings occur only for variables that are candidates for
register allocation.  Therefore, they do not occur for a variable that
is declared <code>volatile</code>, or whose address is taken, or whose size
is other than 1, 2, 4 or 8 bytes.  Also, they do not occur for
structures, unions or arrays, even when they are in registers.

     <p>Note that there may be no warning about a variable that is used only
to compute a value that itself is never used, because such
computations may be deleted by data flow analysis before the warnings
are printed.

     <p>These warnings are made optional because GCC is not smart
enough to see all the reasons why the code might be correct
despite appearing to have an error.  Here is one example of how
this can happen:

     <pre class="smallexample">          {
            int x;
            switch (y)
              {
              case 1: x = 1;
                break;
              case 2: x = 4;
                break;
              case 3: x = 5;
              }
            foo (x);
          }
          </pre>

     <p>If the value of <code>y</code> is always 1, 2 or 3, then <code>x</code> is
always initialized, but GCC doesn't know this.  Here is
another common case:

     <pre class="smallexample">          {
            int save_y;
            if (change_y) save_y = y, y = new_y;
            ...
            if (change_y) y = save_y;
          }
          </pre>

     <p>This has no bug because <code>save_y</code> is used only if it is set.

     <p>This option also warns when a non-volatile automatic variable might be
changed by a call to <code>longjmp</code>.  These warnings as well are possible
only in optimizing compilation.

     <p>The compiler sees only the calls to <code>setjmp</code>.  It cannot know
where <code>longjmp</code> will be called; in fact, a signal handler could
call it at any point in the code.  As a result, you may get a warning
even when there is in fact no problem because <code>longjmp</code> cannot
in fact be called at the place which would cause a problem.

     <p>Some spurious warnings can be avoided if you declare all the functions
you use that never return as <code>noreturn</code>.  See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

     <br><dt><code>-Wunknown-pragmas</code>
     <dd>Warn when a #pragma directive is encountered which is not understood by
GCC.  If this command line option is used, warnings will even be issued
for unknown pragmas in system header files.  This is not the case if
the warnings were only enabled by the <code>-Wall</code> command line option.

     <br><dt><code>-Wstrict-aliasing</code>
     <dd>This option is only active when <code>-fstrict-aliasing</code> is active. 
It warns about code which might break the strict aliasing rules that the
compiler is using for optimization. The warning does not catch all
cases, but does attempt to catch the more common pitfalls. It is
included in <code>-Wall</code>.

     <br><dt><code>-Wstrict-aliasing=2</code>
     <dd>This option is only active when <code>-fstrict-aliasing</code> is active. 
It warns about all code which might break the strict aliasing rules that the
compiler is using for optimization.  This warning catches all cases, but
it will also give a warning for some ambiguous cases that are safe.

     <br><dt><code>-Wall</code>
     <dd>All of the above <code>-W</code> options combined.  This enables all the
warnings about constructions that some users consider questionable, and
that are easy to avoid (or modify to prevent the warning), even in
conjunction with macros.  This also enables some language-specific
warnings described in <a href="C---Dialect-Options.html#C++%20Dialect%20Options">C++ Dialect Options</a> and
<a href="Objective-C-Dialect-Options.html#Objective-C%20Dialect%20Options">Objective-C Dialect Options</a>. 
</dl>

   <p>The following <code>-W...</code> options are not implied by <code>-Wall</code>. 
Some of them warn about constructions that users generally do not
consider questionable, but which occasionally you might wish to check
for; others warn about constructions that are necessary or hard to avoid
in some cases, and there is no simple way to modify the code to suppress
the warning.

     <dl>
<dt><code>-Wextra</code>
     <dd>(This option used to be called <code>-W</code>.  The older name is still
supported, but the newer name is more descriptive.)  Print extra warning
messages for these events:

          <ul>
<li>A function can return either with or without a value.  (Falling
off the end of the function body is considered returning without
a value.)  For example, this function would evoke such a
warning:

          <pre class="smallexample">               foo (a)
               {
                 if (a &gt; 0)
                   return a;
               }
               </pre>

          <li>An expression-statement or the left-hand side of a comma expression
contains no side effects. 
To suppress the warning, cast the unused expression to void. 
For example, an expression such as <code>x[i,j]</code> will cause a warning,
but <code>x[(void)i,j]</code> will not.

          <li>An unsigned value is compared against zero with <code>&lt;</code> or <code>&gt;=</code>.

          <li>A comparison like <code>x&lt;=y&lt;=z</code> appears; this is equivalent to
<code>(x&lt;=y ? 1 : 0) &lt;= z</code>, which is a different interpretation from
that of ordinary mathematical notation.

          <li>Storage-class specifiers like <code>static</code> are not the first things in
a declaration.  According to the C Standard, this usage is obsolescent.

          <li>The return type of a function has a type qualifier such as <code>const</code>. 
Such a type qualifier has no effect, since the value returned by a
function is not an lvalue.  (But don't warn about the GNU extension of
<code>volatile void</code> return types.  That extension will be warned about
if <code>-pedantic</code> is specified.)

          <li>If <code>-Wall</code> or <code>-Wunused</code> is also specified, warn about unused
arguments.

          <li>A comparison between signed and unsigned values could produce an
incorrect result when the signed value is converted to unsigned. 
(But don't warn if <code>-Wno-sign-compare</code> is also specified.)

          <li>An aggregate has an initializer which does not initialize all members. 
For example, the following code would cause such a warning, because
<code>x.h</code> would be implicitly initialized to zero:

          <pre class="smallexample">               struct s { int f, g, h; };
               struct s x = { 3, 4 };
               </pre>

          <li>A function parameter is declared without a type specifier in K&amp;R-style
functions:

          <pre class="smallexample">               void foo(bar) { }
               </pre>

          <li>An empty body occurs in an <code>if</code> or <code>else</code> statement.

          <li>A pointer is compared against integer zero with <code>&lt;</code>, <code>&lt;=</code>,
<code>&gt;</code>, or <code>&gt;=</code>.

          <li>A variable might be changed by <code>longjmp</code> or <code>vfork</code>.

          <li>Any of several floating-point events that often indicate errors, such as
overflow, underflow, loss of precision, etc.

          <li>(C++ only)
An enumerator and a non-enumerator both appear in a conditional expression.

          <li>(C++ only)
A non-static reference or non-static <code>const</code> member appears in a
class without constructors.

          <li>(C++ only)
Ambiguous virtual bases.

          <li>(C++ only)
Subscripting an array which has been declared <code>register</code>.

          <li>(C++ only)
Taking the address of a variable which has been declared <code>register</code>.

          <li>(C++ only)
A base class is not initialized in a derived class' copy constructor. 
</ul>

     <br><dt><code>-Wno-div-by-zero</code>
     <dd>Do not warn about compile-time integer division by zero.  Floating point
division by zero is not warned about, as it can be a legitimate way of
obtaining infinities and NaNs.

     <br><dt><code>-Wsystem-headers</code>
     <dd>Print warning messages for constructs found in system header files. 
Warnings from system headers are normally suppressed, on the assumption
that they usually do not indicate real problems and would only make the
compiler output harder to read.  Using this command line option tells
GCC to emit warnings from system headers as if they occurred in user
code.  However, note that using <code>-Wall</code> in conjunction with this
option will <em>not</em> warn about unknown pragmas in system
headers--for that, <code>-Wunknown-pragmas</code> must also be used.

     <br><dt><code>-Wfloat-equal</code>
     <dd>Warn if floating point values are used in equality comparisons.

     <p>The idea behind this is that sometimes it is convenient (for the
programmer) to consider floating-point values as approximations to
infinitely precise real numbers.  If you are doing this, then you need
to compute (by analyzing the code, or in some other way) the maximum or
likely maximum error that the computation introduces, and allow for it
when performing comparisons (and when producing output, but that's a
different problem).  In particular, instead of testing for equality, you
would check to see whether the two values have ranges that overlap; and
this is done with the relational operators, so equality comparisons are
probably mistaken.