aarch64-linux-gnu-4.9/share/doc/gcc/Non_002dbugs.html - toolchains/linux-x86/gcc - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <html>
 <!-- Copyright (C) 1988-2015 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> &nbsp; [<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">11.8 Certain Changes We Don&rsquo;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&mdash;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&rsquo;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 &ldquo;the
 ABI standard&rdquo; 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
 &ldquo;yes&rdquo;.
 </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.  &lsquo;<samp>gcc -ansi -pedantic</samp>&rsquo; 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 &lsquo;<samp>gcc -ansi</samp>&rsquo;&mdash;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 &ldquo;empty&rdquo; loops.

 <p>Historically, GCC has not deleted &ldquo;empty&rdquo; 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 &lsquo;<samp>2, 3</samp>&rsquo;, or it might get &lsquo;<samp>3, 2</samp>&rsquo;, or even &lsquo;<samp>2, 2</samp>&rsquo;.
 </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 &ldquo;diagnostic&rdquo; 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 &ldquo;failure&rdquo;, 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> &nbsp; [<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>
	<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
	<html>
	<!-- Copyright (C) 1988-2015 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">11.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>