1<html lang="en"> 2<head> 3<title>Non-bugs - Using the GNU Compiler Collection (GCC)</title> 4<meta http-equiv="Content-Type" content="text/html"> 5<meta name="description" content="Using the GNU Compiler Collection (GCC)"> 6<meta name="generator" content="makeinfo 4.13"> 7<link title="Top" rel="start" href="index.html#Top"> 8<link rel="up" href="Trouble.html#Trouble" title="Trouble"> 9<link rel="prev" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings" title="C++ Misunderstandings"> 10<link rel="next" href="Warnings-and-Errors.html#Warnings-and-Errors" title="Warnings and Errors"> 11<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> 12<!-- 13Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 141998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 152010 Free Software Foundation, Inc. 16 17Permission is granted to copy, distribute and/or modify this document 18under the terms of the GNU Free Documentation License, Version 1.3 or 19any later version published by the Free Software Foundation; with the 20Invariant Sections being ``Funding Free Software'', the Front-Cover 21Texts being (a) (see below), and with the Back-Cover Texts being (b) 22(see below). A copy of the license is included in the section entitled 23``GNU Free Documentation License''. 24 25(a) The FSF's Front-Cover Text is: 26 27 A GNU Manual 28 29(b) The FSF's Back-Cover Text is: 30 31 You have freedom to copy and modify this GNU Manual, like GNU 32 software. Copies published by the Free Software Foundation raise 33 funds for GNU development.--> 34<meta http-equiv="Content-Style-Type" content="text/css"> 35<style type="text/css"><!-- 36 pre.display { font-family:inherit } 37 pre.format { font-family:inherit } 38 pre.smalldisplay { font-family:inherit; font-size:smaller } 39 pre.smallformat { font-family:inherit; font-size:smaller } 40 pre.smallexample { font-size:smaller } 41 pre.smalllisp { font-size:smaller } 42 span.sc { font-variant:small-caps } 43 span.roman { font-family:serif; font-weight:normal; } 44 span.sansserif { font-family:sans-serif; font-weight:normal; } 45--></style> 46<link rel="stylesheet" type="text/css" href="../cs.css"> 47</head> 48<body> 49<div class="node"> 50<a name="Non-bugs"></a> 51<a name="Non_002dbugs"></a> 52<p> 53Next: <a rel="next" accesskey="n" href="Warnings-and-Errors.html#Warnings-and-Errors">Warnings and Errors</a>, 54Previous: <a rel="previous" accesskey="p" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings">C++ Misunderstandings</a>, 55Up: <a rel="up" accesskey="u" href="Trouble.html#Trouble">Trouble</a> 56<hr> 57</div> 58 59<h3 class="section">11.9 Certain Changes We Don't Want to Make</h3> 60 61<p>This section lists changes that people frequently request, but which 62we do not make because we think GCC is better without them. 63 64 <ul> 65<li>Checking the number and type of arguments to a function which has an 66old-fashioned definition and no prototype. 67 68 <p>Such a feature would work only occasionally—only for calls that appear 69in the same file as the called function, following the definition. The 70only way to check all calls reliably is to add a prototype for the 71function. But adding a prototype eliminates the motivation for this 72feature. So the feature is not worthwhile. 73 74 <li>Warning about using an expression whose type is signed as a shift count. 75 76 <p>Shift count operands are probably signed more often than unsigned. 77Warning about this would cause far more annoyance than good. 78 79 <li>Warning about assigning a signed value to an unsigned variable. 80 81 <p>Such assignments must be very common; warning about them would cause 82more annoyance than good. 83 84 <li>Warning when a non-void function value is ignored. 85 86 <p>C contains many standard functions that return a value that most 87programs choose to ignore. One obvious example is <code>printf</code>. 88Warning about this practice only leads the defensive programmer to 89clutter programs with dozens of casts to <code>void</code>. Such casts are 90required so frequently that they become visual noise. Writing those 91casts becomes so automatic that they no longer convey useful 92information about the intentions of the programmer. For functions 93where the return value should never be ignored, use the 94<code>warn_unused_result</code> function attribute (see <a href="Function-Attributes.html#Function-Attributes">Function Attributes</a>). 95 96 <li><a name="index-fshort_002denums-3338"></a>Making <samp><span class="option">-fshort-enums</span></samp> the default. 97 98 <p>This would cause storage layout to be incompatible with most other C 99compilers. And it doesn't seem very important, given that you can get 100the same result in other ways. The case where it matters most is when 101the enumeration-valued object is inside a structure, and in that case 102you can specify a field width explicitly. 103 104 <li>Making bit-fields unsigned by default on particular machines where “the 105ABI standard” says to do so. 106 107 <p>The ISO C standard leaves it up to the implementation whether a bit-field 108declared plain <code>int</code> is signed or not. This in effect creates two 109alternative dialects of C. 110 111 <p><a name="index-fsigned_002dbitfields-3339"></a><a name="index-funsigned_002dbitfields-3340"></a>The GNU C compiler supports both dialects; you can specify the signed 112dialect with <samp><span class="option">-fsigned-bitfields</span></samp> and the unsigned dialect with 113<samp><span class="option">-funsigned-bitfields</span></samp>. However, this leaves open the question of 114which dialect to use by default. 115 116 <p>Currently, the preferred dialect makes plain bit-fields signed, because 117this is simplest. Since <code>int</code> is the same as <code>signed int</code> in 118every other context, it is cleanest for them to be the same in bit-fields 119as well. 120 121 <p>Some computer manufacturers have published Application Binary Interface 122standards which specify that plain bit-fields should be unsigned. It is 123a mistake, however, to say anything about this issue in an ABI. This is 124because the handling of plain bit-fields distinguishes two dialects of C. 125Both dialects are meaningful on every type of machine. Whether a 126particular object file was compiled using signed bit-fields or unsigned 127is of no concern to other object files, even if they access the same 128bit-fields in the same data structures. 129 130 <p>A given program is written in one or the other of these two dialects. 131The program stands a chance to work on most any machine if it is 132compiled with the proper dialect. It is unlikely to work at all if 133compiled with the wrong dialect. 134 135 <p>Many users appreciate the GNU C compiler because it provides an 136environment that is uniform across machines. These users would be 137inconvenienced if the compiler treated plain bit-fields differently on 138certain machines. 139 140 <p>Occasionally users write programs intended only for a particular machine 141type. On these occasions, the users would benefit if the GNU C compiler 142were to support by default the same dialect as the other compilers on 143that machine. But such applications are rare. And users writing a 144program to run on more than one type of machine cannot possibly benefit 145from this kind of compatibility. 146 147 <p>This is why GCC does and will treat plain bit-fields in the same 148fashion on all types of machines (by default). 149 150 <p>There are some arguments for making bit-fields unsigned by default on all 151machines. If, for example, this becomes a universal de facto standard, 152it would make sense for GCC to go along with it. This is something 153to be considered in the future. 154 155 <p>(Of course, users strongly concerned about portability should indicate 156explicitly in each bit-field whether it is signed or not. In this way, 157they write programs which have the same meaning in both C dialects.) 158 159 <li><a name="index-ansi-3341"></a><a name="index-std-3342"></a>Undefining <code>__STDC__</code> when <samp><span class="option">-ansi</span></samp> is not used. 160 161 <p>Currently, GCC defines <code>__STDC__</code> unconditionally. This provides 162good results in practice. 163 164 <p>Programmers normally use conditionals on <code>__STDC__</code> to ask whether 165it is safe to use certain features of ISO C, such as function 166prototypes or ISO token concatenation. Since plain <samp><span class="command">gcc</span></samp> supports 167all the features of ISO C, the correct answer to these questions is 168“yes”. 169 170 <p>Some users try to use <code>__STDC__</code> to check for the availability of 171certain library facilities. This is actually incorrect usage in an ISO 172C program, because the ISO C standard says that a conforming 173freestanding implementation should define <code>__STDC__</code> even though it 174does not have the library facilities. ‘<samp><span class="samp">gcc -ansi -pedantic</span></samp>’ is a 175conforming freestanding implementation, and it is therefore required to 176define <code>__STDC__</code>, even though it does not come with an ISO C 177library. 178 179 <p>Sometimes people say that defining <code>__STDC__</code> in a compiler that 180does not completely conform to the ISO C standard somehow violates the 181standard. This is illogical. The standard is a standard for compilers 182that claim to support ISO C, such as ‘<samp><span class="samp">gcc -ansi</span></samp>’—not for other 183compilers such as plain <samp><span class="command">gcc</span></samp>. Whatever the ISO C standard says 184is relevant to the design of plain <samp><span class="command">gcc</span></samp> without <samp><span class="option">-ansi</span></samp> only 185for pragmatic reasons, not as a requirement. 186 187 <p>GCC normally defines <code>__STDC__</code> to be 1, and in addition 188defines <code>__STRICT_ANSI__</code> if you specify the <samp><span class="option">-ansi</span></samp> option, 189or a <samp><span class="option">-std</span></samp> option for strict conformance to some version of ISO C. 190On some hosts, system include files use a different convention, where 191<code>__STDC__</code> is normally 0, but is 1 if the user specifies strict 192conformance to the C Standard. GCC follows the host convention when 193processing system include files, but when processing user files it follows 194the usual GNU C convention. 195 196 <li>Undefining <code>__STDC__</code> in C++. 197 198 <p>Programs written to compile with C++-to-C translators get the 199value of <code>__STDC__</code> that goes with the C compiler that is 200subsequently used. These programs must test <code>__STDC__</code> 201to determine what kind of C preprocessor that compiler uses: 202whether they should concatenate tokens in the ISO C fashion 203or in the traditional fashion. 204 205 <p>These programs work properly with GNU C++ if <code>__STDC__</code> is defined. 206They would not work otherwise. 207 208 <p>In addition, many header files are written to provide prototypes in ISO 209C but not in traditional C. Many of these header files can work without 210change in C++ provided <code>__STDC__</code> is defined. If <code>__STDC__</code> 211is not defined, they will all fail, and will all need to be changed to 212test explicitly for C++ as well. 213 214 <li>Deleting “empty” loops. 215 216 <p>Historically, GCC has not deleted “empty” loops under the 217assumption that the most likely reason you would put one in a program is 218to have a delay, so deleting them will not make real programs run any 219faster. 220 221 <p>However, the rationale here is that optimization of a nonempty loop 222cannot produce an empty one. This held for carefully written C compiled 223with less powerful optimizers but is not always the case for carefully 224written C++ or with more powerful optimizers. 225Thus GCC will remove operations from loops whenever it can determine 226those operations are not externally visible (apart from the time taken 227to execute them, of course). In case the loop can be proved to be finite, 228GCC will also remove the loop itself. 229 230 <p>Be aware of this when performing timing tests, for instance the 231following loop can be completely removed, provided 232<code>some_expression</code> can provably not change any global state. 233 234 <pre class="smallexample"> { 235 int sum = 0; 236 int ix; 237 238 for (ix = 0; ix != 10000; ix++) 239 sum += some_expression; 240 } 241</pre> 242 <p>Even though <code>sum</code> is accumulated in the loop, no use is made of 243that summation, so the accumulation can be removed. 244 245 <li>Making side effects happen in the same order as in some other compiler. 246 247 <p><a name="index-side-effects_002c-order-of-evaluation-3343"></a><a name="index-order-of-evaluation_002c-side-effects-3344"></a>It is never safe to depend on the order of evaluation of side effects. 248For example, a function call like this may very well behave differently 249from one compiler to another: 250 251 <pre class="smallexample"> void func (int, int); 252 253 int i = 2; 254 func (i++, i++); 255</pre> 256 <p>There is no guarantee (in either the C or the C++ standard language 257definitions) that the increments will be evaluated in any particular 258order. Either increment might happen first. <code>func</code> might get the 259arguments ‘<samp><span class="samp">2, 3</span></samp>’, or it might get ‘<samp><span class="samp">3, 2</span></samp>’, or even ‘<samp><span class="samp">2, 2</span></samp>’. 260 261 <li>Making certain warnings into errors by default. 262 263 <p>Some ISO C testsuites report failure when the compiler does not produce 264an error message for a certain program. 265 266 <p><a name="index-pedantic_002derrors-3345"></a>ISO C requires a “diagnostic” message for certain kinds of invalid 267programs, but a warning is defined by GCC to count as a diagnostic. If 268GCC produces a warning but not an error, that is correct ISO C support. 269If testsuites call this “failure”, they should be run with the GCC 270option <samp><span class="option">-pedantic-errors</span></samp>, which will turn these warnings into 271errors. 272 273 </ul> 274 275 </body></html> 276 277