316 lines
15 KiB
HTML
316 lines
15 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- Copyright (C) 1988-2016 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being "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".
|
||
|
|
|
||
|
|
(a) The FSF's Front-Cover Text is:
|
||
|
|
|
||
|
|
A GNU Manual
|
||
|
|
|
||
|
|
(b) The FSF's Back-Cover Text is:
|
||
|
|
|
||
|
|
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. -->
|
||
|
|
<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
|
||
|
|
<head>
|
||
|
|
<title>Using the GNU Compiler Collection (GCC): Non-bugs</title>
|
||
|
|
|
||
|
|
<meta name="description" content="Using the GNU Compiler Collection (GCC): Non-bugs">
|
||
|
|
<meta name="keywords" content="Using the GNU Compiler Collection (GCC): Non-bugs">
|
||
|
|
<meta name="resource-type" content="document">
|
||
|
|
<meta name="distribution" content="global">
|
||
|
|
<meta name="Generator" content="makeinfo">
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<link href="index.html#Top" rel="start" title="Top">
|
||
|
|
<link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
|
||
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
||
|
|
<link href="Trouble.html#Trouble" rel="up" title="Trouble">
|
||
|
|
<link href="Warnings-and-Errors.html#Warnings-and-Errors" rel="next" title="Warnings and Errors">
|
||
|
|
<link href="Copy-Assignment.html#Copy-Assignment" rel="prev" title="Copy Assignment">
|
||
|
|
<style type="text/css">
|
||
|
|
<!--
|
||
|
|
a.summary-letter {text-decoration: none}
|
||
|
|
blockquote.smallquotation {font-size: smaller}
|
||
|
|
div.display {margin-left: 3.2em}
|
||
|
|
div.example {margin-left: 3.2em}
|
||
|
|
div.indentedblock {margin-left: 3.2em}
|
||
|
|
div.lisp {margin-left: 3.2em}
|
||
|
|
div.smalldisplay {margin-left: 3.2em}
|
||
|
|
div.smallexample {margin-left: 3.2em}
|
||
|
|
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
|
||
|
|
div.smalllisp {margin-left: 3.2em}
|
||
|
|
kbd {font-style:oblique}
|
||
|
|
pre.display {font-family: inherit}
|
||
|
|
pre.format {font-family: inherit}
|
||
|
|
pre.menu-comment {font-family: serif}
|
||
|
|
pre.menu-preformatted {font-family: serif}
|
||
|
|
pre.smalldisplay {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smallexample {font-size: smaller}
|
||
|
|
pre.smallformat {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smalllisp {font-size: smaller}
|
||
|
|
span.nocodebreak {white-space:nowrap}
|
||
|
|
span.nolinebreak {white-space:nowrap}
|
||
|
|
span.roman {font-family:serif; font-weight:normal}
|
||
|
|
span.sansserif {font-family:sans-serif; font-weight:normal}
|
||
|
|
ul.no-bullet {list-style: none}
|
||
|
|
-->
|
||
|
|
</style>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
|
||
|
|
<a name="Non_002dbugs"></a>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Warnings-and-Errors.html#Warnings-and-Errors" accesskey="n" rel="next">Warnings and Errors</a>, Previous: <a href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings" accesskey="p" rel="prev">C++ Misunderstandings</a>, Up: <a href="Trouble.html#Trouble" accesskey="u" rel="up">Trouble</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
<hr>
|
||
|
|
<a name="Certain-Changes-We-Don_0027t-Want-to-Make"></a>
|
||
|
|
<h3 class="section">12.8 Certain Changes We Don’t Want to Make</h3>
|
||
|
|
|
||
|
|
<p>This section lists changes that people frequently request, but which
|
||
|
|
we do not make because we think GCC is better without them.
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li> Checking the number and type of arguments to a function which has an
|
||
|
|
old-fashioned definition and no prototype.
|
||
|
|
|
||
|
|
<p>Such a feature would work only occasionally—only for calls that appear
|
||
|
|
in the same file as the called function, following the definition. The
|
||
|
|
only way to check all calls reliably is to add a prototype for the
|
||
|
|
function. But adding a prototype eliminates the motivation for this
|
||
|
|
feature. So the feature is not worthwhile.
|
||
|
|
</p>
|
||
|
|
</li><li> Warning about using an expression whose type is signed as a shift count.
|
||
|
|
|
||
|
|
<p>Shift count operands are probably signed more often than unsigned.
|
||
|
|
Warning about this would cause far more annoyance than good.
|
||
|
|
</p>
|
||
|
|
</li><li> Warning about assigning a signed value to an unsigned variable.
|
||
|
|
|
||
|
|
<p>Such assignments must be very common; warning about them would cause
|
||
|
|
more annoyance than good.
|
||
|
|
</p>
|
||
|
|
</li><li> Warning when a non-void function value is ignored.
|
||
|
|
|
||
|
|
<p>C contains many standard functions that return a value that most
|
||
|
|
programs choose to ignore. One obvious example is <code>printf</code>.
|
||
|
|
Warning about this practice only leads the defensive programmer to
|
||
|
|
clutter programs with dozens of casts to <code>void</code>. Such casts are
|
||
|
|
required so frequently that they become visual noise. Writing those
|
||
|
|
casts becomes so automatic that they no longer convey useful
|
||
|
|
information about the intentions of the programmer. For functions
|
||
|
|
where the return value should never be ignored, use the
|
||
|
|
<code>warn_unused_result</code> function attribute (see <a href="Function-Attributes.html#Function-Attributes">Function Attributes</a>).
|
||
|
|
</p>
|
||
|
|
</li><li> <a name="index-fshort_002denums-3"></a>
|
||
|
|
Making <samp>-fshort-enums</samp> the default.
|
||
|
|
|
||
|
|
<p>This would cause storage layout to be incompatible with most other C
|
||
|
|
compilers. And it doesn’t seem very important, given that you can get
|
||
|
|
the same result in other ways. The case where it matters most is when
|
||
|
|
the enumeration-valued object is inside a structure, and in that case
|
||
|
|
you can specify a field width explicitly.
|
||
|
|
</p>
|
||
|
|
</li><li> Making bit-fields unsigned by default on particular machines where “the
|
||
|
|
ABI standard” says to do so.
|
||
|
|
|
||
|
|
<p>The ISO C standard leaves it up to the implementation whether a bit-field
|
||
|
|
declared plain <code>int</code> is signed or not. This in effect creates two
|
||
|
|
alternative dialects of C.
|
||
|
|
</p>
|
||
|
|
<a name="index-fsigned_002dbitfields-1"></a>
|
||
|
|
<a name="index-funsigned_002dbitfields-2"></a>
|
||
|
|
<p>The GNU C compiler supports both dialects; you can specify the signed
|
||
|
|
dialect with <samp>-fsigned-bitfields</samp> and the unsigned dialect with
|
||
|
|
<samp>-funsigned-bitfields</samp>. However, this leaves open the question of
|
||
|
|
which dialect to use by default.
|
||
|
|
</p>
|
||
|
|
<p>Currently, the preferred dialect makes plain bit-fields signed, because
|
||
|
|
this is simplest. Since <code>int</code> is the same as <code>signed int</code> in
|
||
|
|
every other context, it is cleanest for them to be the same in bit-fields
|
||
|
|
as well.
|
||
|
|
</p>
|
||
|
|
<p>Some computer manufacturers have published Application Binary Interface
|
||
|
|
standards which specify that plain bit-fields should be unsigned. It is
|
||
|
|
a mistake, however, to say anything about this issue in an ABI. This is
|
||
|
|
because the handling of plain bit-fields distinguishes two dialects of C.
|
||
|
|
Both dialects are meaningful on every type of machine. Whether a
|
||
|
|
particular object file was compiled using signed bit-fields or unsigned
|
||
|
|
is of no concern to other object files, even if they access the same
|
||
|
|
bit-fields in the same data structures.
|
||
|
|
</p>
|
||
|
|
<p>A given program is written in one or the other of these two dialects.
|
||
|
|
The program stands a chance to work on most any machine if it is
|
||
|
|
compiled with the proper dialect. It is unlikely to work at all if
|
||
|
|
compiled with the wrong dialect.
|
||
|
|
</p>
|
||
|
|
<p>Many users appreciate the GNU C compiler because it provides an
|
||
|
|
environment that is uniform across machines. These users would be
|
||
|
|
inconvenienced if the compiler treated plain bit-fields differently on
|
||
|
|
certain machines.
|
||
|
|
</p>
|
||
|
|
<p>Occasionally users write programs intended only for a particular machine
|
||
|
|
type. On these occasions, the users would benefit if the GNU C compiler
|
||
|
|
were to support by default the same dialect as the other compilers on
|
||
|
|
that machine. But such applications are rare. And users writing a
|
||
|
|
program to run on more than one type of machine cannot possibly benefit
|
||
|
|
from this kind of compatibility.
|
||
|
|
</p>
|
||
|
|
<p>This is why GCC does and will treat plain bit-fields in the same
|
||
|
|
fashion on all types of machines (by default).
|
||
|
|
</p>
|
||
|
|
<p>There are some arguments for making bit-fields unsigned by default on all
|
||
|
|
machines. If, for example, this becomes a universal de facto standard,
|
||
|
|
it would make sense for GCC to go along with it. This is something
|
||
|
|
to be considered in the future.
|
||
|
|
</p>
|
||
|
|
<p>(Of course, users strongly concerned about portability should indicate
|
||
|
|
explicitly in each bit-field whether it is signed or not. In this way,
|
||
|
|
they write programs which have the same meaning in both C dialects.)
|
||
|
|
</p>
|
||
|
|
</li><li> <a name="index-ansi-4"></a>
|
||
|
|
<a name="index-std-3"></a>
|
||
|
|
Undefining <code>__STDC__</code> when <samp>-ansi</samp> is not used.
|
||
|
|
|
||
|
|
<p>Currently, GCC defines <code>__STDC__</code> unconditionally. This provides
|
||
|
|
good results in practice.
|
||
|
|
</p>
|
||
|
|
<p>Programmers normally use conditionals on <code>__STDC__</code> to ask whether
|
||
|
|
it is safe to use certain features of ISO C, such as function
|
||
|
|
prototypes or ISO token concatenation. Since plain <code>gcc</code> supports
|
||
|
|
all the features of ISO C, the correct answer to these questions is
|
||
|
|
“yes”.
|
||
|
|
</p>
|
||
|
|
<p>Some users try to use <code>__STDC__</code> to check for the availability of
|
||
|
|
certain library facilities. This is actually incorrect usage in an ISO
|
||
|
|
C program, because the ISO C standard says that a conforming
|
||
|
|
freestanding implementation should define <code>__STDC__</code> even though it
|
||
|
|
does not have the library facilities. ‘<samp>gcc -ansi -pedantic</samp>’ is a
|
||
|
|
conforming freestanding implementation, and it is therefore required to
|
||
|
|
define <code>__STDC__</code>, even though it does not come with an ISO C
|
||
|
|
library.
|
||
|
|
</p>
|
||
|
|
<p>Sometimes people say that defining <code>__STDC__</code> in a compiler that
|
||
|
|
does not completely conform to the ISO C standard somehow violates the
|
||
|
|
standard. This is illogical. The standard is a standard for compilers
|
||
|
|
that claim to support ISO C, such as ‘<samp>gcc -ansi</samp>’—not for other
|
||
|
|
compilers such as plain <code>gcc</code>. Whatever the ISO C standard says
|
||
|
|
is relevant to the design of plain <code>gcc</code> without <samp>-ansi</samp> only
|
||
|
|
for pragmatic reasons, not as a requirement.
|
||
|
|
</p>
|
||
|
|
<p>GCC normally defines <code>__STDC__</code> to be 1, and in addition
|
||
|
|
defines <code>__STRICT_ANSI__</code> if you specify the <samp>-ansi</samp> option,
|
||
|
|
or a <samp>-std</samp> option for strict conformance to some version of ISO C.
|
||
|
|
On some hosts, system include files use a different convention, where
|
||
|
|
<code>__STDC__</code> is normally 0, but is 1 if the user specifies strict
|
||
|
|
conformance to the C Standard. GCC follows the host convention when
|
||
|
|
processing system include files, but when processing user files it follows
|
||
|
|
the usual GNU C convention.
|
||
|
|
</p>
|
||
|
|
</li><li> Undefining <code>__STDC__</code> in C++.
|
||
|
|
|
||
|
|
<p>Programs written to compile with C++-to-C translators get the
|
||
|
|
value of <code>__STDC__</code> that goes with the C compiler that is
|
||
|
|
subsequently used. These programs must test <code>__STDC__</code>
|
||
|
|
to determine what kind of C preprocessor that compiler uses:
|
||
|
|
whether they should concatenate tokens in the ISO C fashion
|
||
|
|
or in the traditional fashion.
|
||
|
|
</p>
|
||
|
|
<p>These programs work properly with GNU C++ if <code>__STDC__</code> is defined.
|
||
|
|
They would not work otherwise.
|
||
|
|
</p>
|
||
|
|
<p>In addition, many header files are written to provide prototypes in ISO
|
||
|
|
C but not in traditional C. Many of these header files can work without
|
||
|
|
change in C++ provided <code>__STDC__</code> is defined. If <code>__STDC__</code>
|
||
|
|
is not defined, they will all fail, and will all need to be changed to
|
||
|
|
test explicitly for C++ as well.
|
||
|
|
</p>
|
||
|
|
</li><li> Deleting “empty” loops.
|
||
|
|
|
||
|
|
<p>Historically, GCC has not deleted “empty” loops under the
|
||
|
|
assumption that the most likely reason you would put one in a program is
|
||
|
|
to have a delay, so deleting them will not make real programs run any
|
||
|
|
faster.
|
||
|
|
</p>
|
||
|
|
<p>However, the rationale here is that optimization of a nonempty loop
|
||
|
|
cannot produce an empty one. This held for carefully written C compiled
|
||
|
|
with less powerful optimizers but is not always the case for carefully
|
||
|
|
written C++ or with more powerful optimizers.
|
||
|
|
Thus GCC will remove operations from loops whenever it can determine
|
||
|
|
those operations are not externally visible (apart from the time taken
|
||
|
|
to execute them, of course). In case the loop can be proved to be finite,
|
||
|
|
GCC will also remove the loop itself.
|
||
|
|
</p>
|
||
|
|
<p>Be aware of this when performing timing tests, for instance the
|
||
|
|
following loop can be completely removed, provided
|
||
|
|
<code>some_expression</code> can provably not change any global state.
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">{
|
||
|
|
int sum = 0;
|
||
|
|
int ix;
|
||
|
|
|
||
|
|
for (ix = 0; ix != 10000; ix++)
|
||
|
|
sum += some_expression;
|
||
|
|
}
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>Even though <code>sum</code> is accumulated in the loop, no use is made of
|
||
|
|
that summation, so the accumulation can be removed.
|
||
|
|
</p>
|
||
|
|
</li><li> Making side effects happen in the same order as in some other compiler.
|
||
|
|
|
||
|
|
<a name="index-side-effects_002c-order-of-evaluation"></a>
|
||
|
|
<a name="index-order-of-evaluation_002c-side-effects"></a>
|
||
|
|
<p>It is never safe to depend on the order of evaluation of side effects.
|
||
|
|
For example, a function call like this may very well behave differently
|
||
|
|
from one compiler to another:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">void func (int, int);
|
||
|
|
|
||
|
|
int i = 2;
|
||
|
|
func (i++, i++);
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>There is no guarantee (in either the C or the C++ standard language
|
||
|
|
definitions) that the increments will be evaluated in any particular
|
||
|
|
order. Either increment might happen first. <code>func</code> might get the
|
||
|
|
arguments ‘<samp>2, 3</samp>’, or it might get ‘<samp>3, 2</samp>’, or even ‘<samp>2, 2</samp>’.
|
||
|
|
</p>
|
||
|
|
</li><li> Making certain warnings into errors by default.
|
||
|
|
|
||
|
|
<p>Some ISO C testsuites report failure when the compiler does not produce
|
||
|
|
an error message for a certain program.
|
||
|
|
</p>
|
||
|
|
<a name="index-pedantic_002derrors-3"></a>
|
||
|
|
<p>ISO C requires a “diagnostic” message for certain kinds of invalid
|
||
|
|
programs, but a warning is defined by GCC to count as a diagnostic. If
|
||
|
|
GCC produces a warning but not an error, that is correct ISO C support.
|
||
|
|
If testsuites call this “failure”, they should be run with the GCC
|
||
|
|
option <samp>-pedantic-errors</samp>, which will turn these warnings into
|
||
|
|
errors.
|
||
|
|
</p>
|
||
|
|
</li></ul>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Warnings-and-Errors.html#Warnings-and-Errors" accesskey="n" rel="next">Warnings and Errors</a>, Previous: <a href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings" accesskey="p" rel="prev">C++ Misunderstandings</a>, Up: <a href="Trouble.html#Trouble" accesskey="u" rel="up">Trouble</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|