📄 warning-options.html
字号:
<html lang="en">
<head>
<title>Using the GNU Compiler Collection (GCC)</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Using the GNU Compiler Collection (GCC)">
<meta name="generator" content="makeinfo 4.3">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
<!--
Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
<p>Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding
Free Software", the Front-Cover texts being (a) (see below), and with
the Back-Cover Texts being (b) (see below). A copy of the license is
included in the section entitled "GNU Free Documentation License".
<p>(a) The FSF's Front-Cover Text is:
<p>A GNU Manual
<p>(b) The FSF's Back-Cover Text is:
<p>You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.-->
</head>
<body>
<div class="node">
<p>
Node:<a name="Warning%20Options">Warning Options</a>,
Next:<a rel="next" accesskey="n" href="Debugging-Options.html#Debugging%20Options">Debugging Options</a>,
Previous:<a rel="previous" accesskey="p" href="Language-Independent-Options.html#Language%20Independent%20Options">Language Independent Options</a>,
Up:<a rel="up" accesskey="u" href="Invoking-GCC.html#Invoking%20GCC">Invoking GCC</a>
<hr><br>
</div>
<h3 class="section">Options to Request or Suppress Warnings</h3>
<p>Warnings are diagnostic messages that report constructions which
are not inherently erroneous but which are risky or suggest there
may have been an error.
<p>You can request many specific warnings with options beginning <code>-W</code>,
for example <code>-Wimplicit</code> to request warnings on implicit
declarations. Each of these specific warning options also has a
negative form beginning <code>-Wno-</code> to turn off warnings;
for example, <code>-Wno-implicit</code>. This manual lists only one of the
two forms, whichever is not the default.
<p>The following options control the amount and kinds of warnings produced
by GCC; for further, language-specific options also refer to
<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>
<dt><code>-fsyntax-only</code>
<dd>Check the code for syntax errors, but don't do anything beyond that.
<br><dt><code>-pedantic</code>
<dd>Issue all the warnings demanded by strict ISO C and ISO C++;
reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO C++. For ISO C, follows the
version of the ISO C standard specified by any <code>-std</code> option used.
<p>Valid ISO C and ISO C++ programs should compile properly with or without
this option (though a rare few will require <code>-ansi</code> or a
<code>-std</code> option specifying the required version of ISO C). However,
without this option, certain GNU extensions and traditional C and C++
features are supported as well. With this option, they are rejected.
<p><code>-pedantic</code> does not cause warning messages for use of the
alternate keywords whose names begin and end with <code>__</code>. Pedantic
warnings are also disabled in the expression that follows
<code>__extension__</code>. However, only system header files should use
these escape routes; application programs should avoid them.
See <a href="Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>.
<p>Some users try to use <code>-pedantic</code> to check programs for strict ISO
C conformance. They soon find that it does not do quite what they want:
it finds some non-ISO practices, but not all--only those for which
ISO C <em>requires</em> a diagnostic, and some others for which
diagnostics have been added.
<p>A feature to report any failure to conform to ISO C might be useful in
some instances, but would require considerable additional work and would
be quite different from <code>-pedantic</code>. We don't have plans to
support such a feature in the near future.
<p>Where the standard specified with <code>-std</code> represents a GNU
extended dialect of C, such as <code>gnu89</code> or <code>gnu99</code>, there is a
corresponding <dfn>base standard</dfn>, the version of ISO C on which the GNU
extended dialect is based. Warnings from <code>-pedantic</code> are given
where they are required by the base standard. (It would not make sense
for such warnings to be given only for features not in the specified GNU
C dialect, since by definition the GNU dialects of C include all
features the compiler supports with the given option, and there would be
nothing to warn about.)
<br><dt><code>-pedantic-errors</code>
<dd>Like <code>-pedantic</code>, except that errors are produced rather than
warnings.
<br><dt><code>-w</code>
<dd>Inhibit all warning messages.
<br><dt><code>-Wno-import</code>
<dd>Inhibit warning messages about the use of <code>#import</code>.
<br><dt><code>-Wchar-subscripts</code>
<dd>Warn if an array subscript has type <code>char</code>. This is a common cause
of error, as programmers often forget that this type is signed on some
machines.
<br><dt><code>-Wcomment</code>
<dd>Warn whenever a comment-start sequence <code>/*</code> appears in a <code>/*</code>
comment, or whenever a Backslash-Newline appears in a <code>//</code> comment.
<br><dt><code>-Wformat</code>
<dd>Check calls to <code>printf</code> and <code>scanf</code>, etc., to make sure that
the arguments supplied have types appropriate to the format string
specified, and that the conversions specified in the format string make
sense. This includes standard functions, and others specified by format
attributes (see <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>), in the <code>printf</code>,
<code>scanf</code>, <code>strftime</code> and <code>strfmon</code> (an X/Open extension,
not in the C standard) families.
<p>The formats are checked against the format features supported by GNU
libc version 2.2. These include all ISO C90 and C99 features, as well
as features from the Single Unix Specification and some BSD and GNU
extensions. Other library implementations may not support all these
features; GCC does not support warning about features that go beyond a
particular library's limitations. However, if <code>-pedantic</code> is used
with <code>-Wformat</code>, warnings will be given about format features not
in the selected standard version (but not for <code>strfmon</code> formats,
since those are not in any version of the C standard). See <a href="C-Dialect-Options.html#C%20Dialect%20Options">Options Controlling C Dialect</a>.
<p>Since <code>-Wformat</code> also checks for null format arguments for
several functions, <code>-Wformat</code> also implies <code>-Wnonnull</code>.
<p><code>-Wformat</code> is included in <code>-Wall</code>. For more control over some
aspects of format checking, the options <code>-Wno-format-y2k</code>,
<code>-Wno-format-extra-args</code>, <code>-Wno-format-zero-length</code>,
<code>-Wformat-nonliteral</code>, <code>-Wformat-security</code>, and
<code>-Wformat=2</code> are available, but are not included in <code>-Wall</code>.
<br><dt><code>-Wno-format-y2k</code>
<dd>If <code>-Wformat</code> is specified, do not warn about <code>strftime</code>
formats which may yield only a two-digit year.
<br><dt><code>-Wno-format-extra-args</code>
<dd>If <code>-Wformat</code> is specified, do not warn about excess arguments to a
<code>printf</code> or <code>scanf</code> format function. The C standard specifies
that such arguments are ignored.
<p>Where the unused arguments lie between used arguments that are
specified with <code>$</code> operand number specifications, normally
warnings are still given, since the implementation could not know what
type to pass to <code>va_arg</code> to skip the unused arguments. However,
in the case of <code>scanf</code> formats, this option will suppress the
warning if the unused arguments are all pointers, since the Single
Unix Specification says that such unused arguments are allowed.
<br><dt><code>-Wno-format-zero-length</code>
<dd>If <code>-Wformat</code> is specified, do not warn about zero-length formats.
The C standard specifies that zero-length formats are allowed.
<br><dt><code>-Wformat-nonliteral</code>
<dd>If <code>-Wformat</code> is specified, also warn if the format string is not a
string literal and so cannot be checked, unless the format function
takes its format arguments as a <code>va_list</code>.
<br><dt><code>-Wformat-security</code>
<dd>If <code>-Wformat</code> is specified, also warn about uses of format
functions that represent possible security problems. At present, this
warns about calls to <code>printf</code> and <code>scanf</code> functions where the
format string is not a string literal and there are no format arguments,
as in <code>printf (foo);</code>. This may be a security hole if the format
string came from untrusted input and contains <code>%n</code>. (This is
currently a subset of what <code>-Wformat-nonliteral</code> warns about, but
in future warnings may be added to <code>-Wformat-security</code> that are not
included in <code>-Wformat-nonliteral</code>.)
<br><dt><code>-Wformat=2</code>
<dd>Enable <code>-Wformat</code> plus format checks not included in
<code>-Wformat</code>. Currently equivalent to <code>-Wformat
-Wformat-nonliteral -Wformat-security</code>.
<br><dt><code>-Wnonnull</code>
<dd>Enable warning about passing a null pointer for arguments marked as
requiring a non-null value by the <code>nonnull</code> function attribute.
<p><code>-Wnonnull</code> is included in <code>-Wall</code> and <code>-Wformat</code>. It
can be disabled with the <code>-Wno-nonnull</code> option.
<br><dt><code>-Wimplicit-int</code>
<dd>Warn when a declaration does not specify a type.
<br><dt><code>-Wimplicit-function-declaration</code>
<dd><dt><code>-Werror-implicit-function-declaration</code>
<dd>Give a warning (or error) whenever a function is used before being
declared.
<br><dt><code>-Wimplicit</code>
<dd>Same as <code>-Wimplicit-int</code> and <code>-Wimplicit-function-declaration</code>.
<br><dt><code>-Wmain</code>
<dd>Warn if the type of <code>main</code> is suspicious. <code>main</code> should be a
function with external linkage, returning int, taking either zero
arguments, two, or three arguments of appropriate types.
<br><dt><code>-Wmissing-braces</code>
<dd>Warn if an aggregate or union initializer is not fully bracketed. In
the following example, the initializer for <code>a</code> is not fully
bracketed, but that for <code>b</code> is fully bracketed.
<pre class="smallexample"> int a[2][2] = { 0, 1, 2, 3 };
int b[2][2] = { { 0, 1 }, { 2, 3 } };
</pre>
<br><dt><code>-Wparentheses</code>
<dd>Warn if parentheses are omitted in certain contexts, such
as when there is an assignment in a context where a truth value
is expected, or when operators are nested whose precedence people
often get confused about.
<p>Also warn about constructions where there may be confusion to which
<code>if</code> statement an <code>else</code> branch belongs. Here is an example of
such a case:
<pre class="smallexample"> {
if (a)
if (b)
foo ();
else
bar ();
}
</pre>
<p>In C, every <code>else</code> branch belongs to the innermost possible <code>if</code>
statement, which in this example is <code>if (b)</code>. This is often not
what the programmer expected, as illustrated in the above example by
indentation the programmer chose. When there is the potential for this
confusion, GCC will issue a warning when this flag is specified.
To eliminate the warning, add explicit braces around the innermost
<code>if</code> statement so there is no way the <code>else</code> could belong to
the enclosing <code>if</code>. The resulting code would look like this:
<pre class="smallexample"> {
if (a)
{
if (b)
foo ();
else
bar ();
}
}
</pre>
<br><dt><code>-Wsequence-point</code>
<dd>Warn about code that may have undefined semantics because of violations
of sequence point rules in the C standard.
<p>The C standard defines the order in which expressions in a C program are
evaluated in terms of <dfn>sequence points</dfn>, which represent a partial
ordering between the execution of parts of the program: those executed
before the sequence point, and those executed after it. These occur
after the evaluation of a full expression (one which is not part of a
larger expression), after the evaluation of the first operand of a
<code>&&</code>, <code>||</code>, <code>? :</code> or <code>,</code> (comma) operator, before a
function is called (but after the evaluation of its arguments and the
expression denoting the called function), and in certain other places.
Other than as expressed by the sequence point rules, the order of
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -