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