Mercurial > hg > CbC > CbC_gcc
annotate gcc/doc/trouble.texi @ 158:494b0b89df80 default tip
...
| author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Mon, 25 May 2020 18:13:55 +0900 |
| parents | 1830386684a0 |
| children |
| rev | line source |
|---|---|
| 145 | 1 @c Copyright (C) 1988-2020 Free Software Foundation, Inc. |
| 0 | 2 @c This is part of the GCC manual. |
| 3 @c For copying conditions, see the file gcc.texi. | |
| 4 | |
| 5 @node Trouble | |
| 6 @chapter Known Causes of Trouble with GCC | |
| 7 @cindex bugs, known | |
| 8 @cindex installation trouble | |
| 9 @cindex known causes of trouble | |
| 10 | |
| 11 This section describes known problems that affect users of GCC@. Most | |
| 12 of these are not GCC bugs per se---if they were, we would fix them. | |
| 13 But the result for a user may be like the result of a bug. | |
| 14 | |
| 15 Some of these problems are due to bugs in other software, some are | |
| 16 missing features that are too much work to add, and some are places | |
| 17 where people's opinions differ as to what is best. | |
| 18 | |
| 19 @menu | |
| 20 * Actual Bugs:: Bugs we will fix later. | |
| 21 * Interoperation:: Problems using GCC with other compilers, | |
| 22 and with certain linkers, assemblers and debuggers. | |
| 23 * Incompatibilities:: GCC is incompatible with traditional C. | |
| 24 * Fixed Headers:: GCC uses corrected versions of system header files. | |
| 25 This is necessary, but doesn't always work smoothly. | |
| 26 * Standard Libraries:: GCC uses the system C library, which might not be | |
| 27 compliant with the ISO C standard. | |
| 111 | 28 * Disappointments:: Regrettable things we cannot change, but not quite bugs. |
| 0 | 29 * C++ Misunderstandings:: Common misunderstandings with GNU C++. |
| 30 * Non-bugs:: Things we think are right, but some others disagree. | |
| 31 * Warnings and Errors:: Which problems in your code get warnings, | |
| 32 and which get errors. | |
| 33 @end menu | |
| 34 | |
| 35 @node Actual Bugs | |
| 36 @section Actual Bugs We Haven't Fixed Yet | |
| 37 | |
| 38 @itemize @bullet | |
| 39 @item | |
| 40 The @code{fixincludes} script interacts badly with automounters; if the | |
| 41 directory of system header files is automounted, it tends to be | |
| 42 unmounted while @code{fixincludes} is running. This would seem to be a | |
| 43 bug in the automounter. We don't know any good way to work around it. | |
| 44 @end itemize | |
| 45 | |
| 46 @node Interoperation | |
| 47 @section Interoperation | |
| 48 | |
| 49 This section lists various difficulties encountered in using GCC | |
| 50 together with other compilers or with the assemblers, linkers, | |
| 51 libraries and debuggers on certain systems. | |
| 52 | |
| 53 @itemize @bullet | |
| 54 @item | |
| 55 On many platforms, GCC supports a different ABI for C++ than do other | |
| 56 compilers, so the object files compiled by GCC cannot be used with object | |
| 57 files generated by another C++ compiler. | |
| 58 | |
| 59 An area where the difference is most apparent is name mangling. The use | |
| 60 of different name mangling is intentional, to protect you from more subtle | |
| 61 problems. | |
| 62 Compilers differ as to many internal details of C++ implementation, | |
| 63 including: how class instances are laid out, how multiple inheritance is | |
| 64 implemented, and how virtual function calls are handled. If the name | |
| 65 encoding were made the same, your programs would link against libraries | |
| 66 provided from other compilers---but the programs would then crash when | |
| 67 run. Incompatible libraries are then detected at link time, rather than | |
| 68 at run time. | |
| 69 | |
| 70 @item | |
| 71 On some BSD systems, including some versions of Ultrix, use of profiling | |
| 72 causes static variable destructors (currently used only in C++) not to | |
| 73 be run. | |
| 74 | |
| 75 @item | |
| 76 On a SPARC, GCC aligns all values of type @code{double} on an 8-byte | |
| 77 boundary, and it expects every @code{double} to be so aligned. The Sun | |
| 78 compiler usually gives @code{double} values 8-byte alignment, with one | |
| 79 exception: function arguments of type @code{double} may not be aligned. | |
| 80 | |
| 81 As a result, if a function compiled with Sun CC takes the address of an | |
| 82 argument of type @code{double} and passes this pointer of type | |
| 83 @code{double *} to a function compiled with GCC, dereferencing the | |
| 84 pointer may cause a fatal signal. | |
| 85 | |
| 86 One way to solve this problem is to compile your entire program with GCC@. | |
| 87 Another solution is to modify the function that is compiled with | |
| 88 Sun CC to copy the argument into a local variable; local variables | |
| 89 are always properly aligned. A third solution is to modify the function | |
| 90 that uses the pointer to dereference it via the following function | |
| 91 @code{access_double} instead of directly with @samp{*}: | |
| 92 | |
| 93 @smallexample | |
| 94 inline double | |
| 95 access_double (double *unaligned_ptr) | |
| 96 @{ | |
| 97 union d2i @{ double d; int i[2]; @}; | |
| 98 | |
| 99 union d2i *p = (union d2i *) unaligned_ptr; | |
| 100 union d2i u; | |
| 101 | |
| 102 u.i[0] = p->i[0]; | |
| 103 u.i[1] = p->i[1]; | |
| 104 | |
| 105 return u.d; | |
| 106 @} | |
| 107 @end smallexample | |
| 108 | |
| 109 @noindent | |
| 110 Storing into the pointer can be done likewise with the same union. | |
| 111 | |
| 112 @item | |
| 113 On Solaris, the @code{malloc} function in the @file{libmalloc.a} library | |
| 114 may allocate memory that is only 4 byte aligned. Since GCC on the | |
| 115 SPARC assumes that doubles are 8 byte aligned, this may result in a | |
| 116 fatal signal if doubles are stored in memory allocated by the | |
| 117 @file{libmalloc.a} library. | |
| 118 | |
| 119 The solution is to not use the @file{libmalloc.a} library. Use instead | |
| 120 @code{malloc} and related functions from @file{libc.a}; they do not have | |
| 121 this problem. | |
| 122 | |
| 123 @item | |
| 124 On the HP PA machine, ADB sometimes fails to work on functions compiled | |
| 125 with GCC@. Specifically, it fails to work on functions that use | |
| 126 @code{alloca} or variable-size arrays. This is because GCC doesn't | |
| 127 generate HP-UX unwind descriptors for such functions. It may even be | |
| 128 impossible to generate them. | |
| 129 | |
| 130 @item | |
| 131 Debugging (@option{-g}) is not supported on the HP PA machine, unless you use | |
| 132 the preliminary GNU tools. | |
| 133 | |
| 134 @item | |
| 135 Taking the address of a label may generate errors from the HP-UX | |
| 136 PA assembler. GAS for the PA does not have this problem. | |
| 137 | |
| 138 @item | |
| 139 Using floating point parameters for indirect calls to static functions | |
| 140 will not work when using the HP assembler. There simply is no way for GCC | |
| 141 to specify what registers hold arguments for static functions when using | |
| 142 the HP assembler. GAS for the PA does not have this problem. | |
| 143 | |
| 144 @item | |
| 145 In extremely rare cases involving some very large functions you may | |
| 146 receive errors from the HP linker complaining about an out of bounds | |
| 147 unconditional branch offset. This used to occur more often in previous | |
| 148 versions of GCC, but is now exceptionally rare. If you should run | |
| 149 into it, you can work around by making your function smaller. | |
| 150 | |
| 151 @item | |
| 152 GCC compiled code sometimes emits warnings from the HP-UX assembler of | |
| 153 the form: | |
| 154 | |
| 155 @smallexample | |
| 156 (warning) Use of GR3 when | |
| 157 frame >= 8192 may cause conflict. | |
| 158 @end smallexample | |
| 159 | |
| 160 These warnings are harmless and can be safely ignored. | |
| 161 | |
| 162 @item | |
| 163 In extremely rare cases involving some very large functions you may | |
| 164 receive errors from the AIX Assembler complaining about a displacement | |
| 165 that is too large. If you should run into it, you can work around by | |
| 166 making your function smaller. | |
| 167 | |
| 168 @item | |
| 169 The @file{libstdc++.a} library in GCC relies on the SVR4 dynamic | |
| 170 linker semantics which merges global symbols between libraries and | |
| 171 applications, especially necessary for C++ streams functionality. | |
| 172 This is not the default behavior of AIX shared libraries and dynamic | |
| 173 linking. @file{libstdc++.a} is built on AIX with ``runtime-linking'' | |
| 174 enabled so that symbol merging can occur. To utilize this feature, | |
| 175 the application linked with @file{libstdc++.a} must include the | |
| 176 @option{-Wl,-brtl} flag on the link line. G++ cannot impose this | |
| 177 because this option may interfere with the semantics of the user | |
| 178 program and users may not always use @samp{g++} to link his or her | |
| 179 application. Applications are not required to use the | |
| 180 @option{-Wl,-brtl} flag on the link line---the rest of the | |
| 181 @file{libstdc++.a} library which is not dependent on the symbol | |
| 182 merging semantics will continue to function correctly. | |
| 183 | |
| 184 @item | |
| 185 An application can interpose its own definition of functions for | |
| 186 functions invoked by @file{libstdc++.a} with ``runtime-linking'' | |
| 187 enabled on AIX@. To accomplish this the application must be linked | |
| 188 with ``runtime-linking'' option and the functions explicitly must be | |
| 189 exported by the application (@option{-Wl,-brtl,-bE:exportfile}). | |
| 190 | |
| 191 @item | |
| 192 AIX on the RS/6000 provides support (NLS) for environments outside of | |
| 193 the United States. Compilers and assemblers use NLS to support | |
| 194 locale-specific representations of various objects including | |
| 195 floating-point numbers (@samp{.} vs @samp{,} for separating decimal | |
| 196 fractions). There have been problems reported where the library linked | |
| 197 with GCC does not produce the same floating-point formats that the | |
| 198 assembler accepts. If you have this problem, set the @env{LANG} | |
| 199 environment variable to @samp{C} or @samp{En_US}. | |
| 200 | |
| 201 @item | |
| 202 @opindex fdollars-in-identifiers | |
| 203 Even if you specify @option{-fdollars-in-identifiers}, | |
| 204 you cannot successfully use @samp{$} in identifiers on the RS/6000 due | |
| 205 to a restriction in the IBM assembler. GAS supports these | |
| 206 identifiers. | |
| 207 | |
| 208 @end itemize | |
| 209 | |
| 210 @node Incompatibilities | |
| 211 @section Incompatibilities of GCC | |
| 212 @cindex incompatibilities of GCC | |
| 213 @opindex traditional | |
| 214 | |
| 215 There are several noteworthy incompatibilities between GNU C and K&R | |
| 216 (non-ISO) versions of C@. | |
| 217 | |
| 218 @itemize @bullet | |
| 219 @cindex string constants | |
| 220 @cindex read-only strings | |
| 221 @cindex shared strings | |
| 222 @item | |
| 223 GCC normally makes string constants read-only. If several | |
| 224 identical-looking string constants are used, GCC stores only one | |
| 225 copy of the string. | |
| 226 | |
| 227 @cindex @code{mktemp}, and constant strings | |
| 228 One consequence is that you cannot call @code{mktemp} with a string | |
| 229 constant argument. The function @code{mktemp} always alters the | |
| 230 string its argument points to. | |
| 231 | |
| 232 @cindex @code{sscanf}, and constant strings | |
| 233 @cindex @code{fscanf}, and constant strings | |
| 234 @cindex @code{scanf}, and constant strings | |
| 235 Another consequence is that @code{sscanf} does not work on some very | |
| 236 old systems when passed a string constant as its format control string | |
| 237 or input. This is because @code{sscanf} incorrectly tries to write | |
| 238 into the string constant. Likewise @code{fscanf} and @code{scanf}. | |
| 239 | |
| 240 The solution to these problems is to change the program to use | |
| 241 @code{char}-array variables with initialization strings for these | |
| 242 purposes instead of string constants. | |
| 243 | |
| 244 @item | |
| 245 @code{-2147483648} is positive. | |
| 246 | |
| 247 This is because 2147483648 cannot fit in the type @code{int}, so | |
| 248 (following the ISO C rules) its data type is @code{unsigned long int}. | |
| 249 Negating this value yields 2147483648 again. | |
| 250 | |
| 251 @item | |
| 252 GCC does not substitute macro arguments when they appear inside of | |
| 253 string constants. For example, the following macro in GCC | |
| 254 | |
| 255 @smallexample | |
| 256 #define foo(a) "a" | |
| 257 @end smallexample | |
| 258 | |
| 259 @noindent | |
| 260 will produce output @code{"a"} regardless of what the argument @var{a} is. | |
| 261 | |
| 262 @cindex @code{setjmp} incompatibilities | |
| 263 @cindex @code{longjmp} incompatibilities | |
| 264 @item | |
| 265 When you use @code{setjmp} and @code{longjmp}, the only automatic | |
| 266 variables guaranteed to remain valid are those declared | |
| 267 @code{volatile}. This is a consequence of automatic register | |
| 268 allocation. Consider this function: | |
| 269 | |
| 270 @smallexample | |
| 271 jmp_buf j; | |
| 272 | |
| 273 foo () | |
| 274 @{ | |
| 275 int a, b; | |
| 276 | |
| 277 a = fun1 (); | |
| 278 if (setjmp (j)) | |
| 279 return a; | |
| 280 | |
| 281 a = fun2 (); | |
| 282 /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ | |
| 283 return a + fun3 (); | |
| 284 @} | |
| 285 @end smallexample | |
| 286 | |
| 287 Here @code{a} may or may not be restored to its first value when the | |
| 288 @code{longjmp} occurs. If @code{a} is allocated in a register, then | |
| 289 its first value is restored; otherwise, it keeps the last value stored | |
| 290 in it. | |
| 291 | |
| 292 @opindex W | |
| 293 If you use the @option{-W} option with the @option{-O} option, you will | |
| 294 get a warning when GCC thinks such a problem might be possible. | |
| 295 | |
| 296 @item | |
| 297 Programs that use preprocessing directives in the middle of macro | |
| 298 arguments do not work with GCC@. For example, a program like this | |
| 299 will not work: | |
| 300 | |
| 301 @smallexample | |
| 302 @group | |
| 303 foobar ( | |
| 304 #define luser | |
| 305 hack) | |
| 306 @end group | |
| 307 @end smallexample | |
| 308 | |
| 309 ISO C does not permit such a construct. | |
| 310 | |
| 311 @item | |
| 312 K&R compilers allow comments to cross over an inclusion boundary | |
| 313 (i.e.@: started in an include file and ended in the including file). | |
| 314 | |
| 315 @cindex external declaration scope | |
| 316 @cindex scope of external declarations | |
| 317 @cindex declaration scope | |
| 318 @item | |
| 319 Declarations of external variables and functions within a block apply | |
| 320 only to the block containing the declaration. In other words, they | |
| 321 have the same scope as any other declaration in the same place. | |
| 322 | |
|
55
77e2b8dfacca
update it from 4.4.3 to 4.5.0
ryoma <e075725@ie.u-ryukyu.ac.jp>
parents:
0
diff
changeset
|
323 In some other C compilers, an @code{extern} declaration affects all the |
| 0 | 324 rest of the file even if it happens within a block. |
| 325 | |
| 326 @item | |
| 327 In traditional C, you can combine @code{long}, etc., with a typedef name, | |
| 328 as shown here: | |
| 329 | |
| 330 @smallexample | |
| 331 typedef int foo; | |
| 332 typedef long foo bar; | |
| 333 @end smallexample | |
| 334 | |
| 335 In ISO C, this is not allowed: @code{long} and other type modifiers | |
| 336 require an explicit @code{int}. | |
| 337 | |
| 338 @cindex typedef names as function parameters | |
| 339 @item | |
| 340 PCC allows typedef names to be used as function parameters. | |
| 341 | |
| 342 @item | |
| 343 Traditional C allows the following erroneous pair of declarations to | |
| 344 appear together in a given scope: | |
| 345 | |
| 346 @smallexample | |
| 347 typedef int foo; | |
| 348 typedef foo foo; | |
| 349 @end smallexample | |
| 350 | |
| 351 @item | |
| 352 GCC treats all characters of identifiers as significant. According to | |
| 353 K&R-1 (2.2), ``No more than the first eight characters are significant, | |
| 354 although more may be used.''. Also according to K&R-1 (2.2), ``An | |
| 355 identifier is a sequence of letters and digits; the first character must | |
| 356 be a letter. The underscore _ counts as a letter.'', but GCC also | |
| 357 allows dollar signs in identifiers. | |
| 358 | |
| 359 @cindex whitespace | |
| 360 @item | |
| 361 PCC allows whitespace in the middle of compound assignment operators | |
| 362 such as @samp{+=}. GCC, following the ISO standard, does not | |
| 363 allow this. | |
| 364 | |
| 365 @cindex apostrophes | |
|
67
f6334be47118
update gcc from gcc-4.6-20100522 to gcc-4.6-20110318
nobuyasu <dimolto@cr.ie.u-ryukyu.ac.jp>
parents:
63
diff
changeset
|
366 @cindex @code{'} |
| 0 | 367 @item |
| 368 GCC complains about unterminated character constants inside of | |
| 369 preprocessing conditionals that fail. Some programs have English | |
| 370 comments enclosed in conditionals that are guaranteed to fail; if these | |
| 371 comments contain apostrophes, GCC will probably report an error. For | |
| 372 example, this code would produce an error: | |
| 373 | |
| 374 @smallexample | |
| 375 #if 0 | |
| 376 You can't expect this to work. | |
| 377 #endif | |
| 378 @end smallexample | |
| 379 | |
| 380 The best solution to such a problem is to put the text into an actual | |
| 381 C comment delimited by @samp{/*@dots{}*/}. | |
| 382 | |
| 383 @item | |
| 384 Many user programs contain the declaration @samp{long time ();}. In the | |
| 385 past, the system header files on many systems did not actually declare | |
| 386 @code{time}, so it did not matter what type your program declared it to | |
| 387 return. But in systems with ISO C headers, @code{time} is declared to | |
| 388 return @code{time_t}, and if that is not the same as @code{long}, then | |
| 389 @samp{long time ();} is erroneous. | |
| 390 | |
| 391 The solution is to change your program to use appropriate system headers | |
| 392 (@code{<time.h>} on systems with ISO C headers) and not to declare | |
| 393 @code{time} if the system header files declare it, or failing that to | |
| 394 use @code{time_t} as the return type of @code{time}. | |
| 395 | |
| 396 @cindex @code{float} as function value type | |
| 397 @item | |
| 398 When compiling functions that return @code{float}, PCC converts it to | |
| 399 a double. GCC actually returns a @code{float}. If you are concerned | |
| 400 with PCC compatibility, you should declare your functions to return | |
| 401 @code{double}; you might as well say what you mean. | |
| 402 | |
| 403 @cindex structures | |
| 404 @cindex unions | |
| 405 @item | |
| 406 When compiling functions that return structures or unions, GCC | |
| 407 output code normally uses a method different from that used on most | |
| 408 versions of Unix. As a result, code compiled with GCC cannot call | |
| 409 a structure-returning function compiled with PCC, and vice versa. | |
| 410 | |
| 411 The method used by GCC is as follows: a structure or union which is | |
| 412 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union | |
| 413 with any other size is stored into an address supplied by the caller | |
| 414 (usually in a special, fixed register, but on some machines it is passed | |
| 415 on the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX} | |
| 416 tells GCC where to pass this address. | |
| 417 | |
| 418 By contrast, PCC on most target machines returns structures and unions | |
| 419 of any size by copying the data into an area of static storage, and then | |
| 420 returning the address of that storage as if it were a pointer value. | |
| 421 The caller must copy the data from that memory area to the place where | |
| 422 the value is wanted. GCC does not use this method because it is | |
| 423 slower and nonreentrant. | |
| 424 | |
| 425 On some newer machines, PCC uses a reentrant convention for all | |
| 426 structure and union returning. GCC on most of these machines uses a | |
| 427 compatible convention when returning structures and unions in memory, | |
| 428 but still returns small structures and unions in registers. | |
| 429 | |
| 430 @opindex fpcc-struct-return | |
| 431 You can tell GCC to use a compatible convention for all structure and | |
| 432 union returning with the option @option{-fpcc-struct-return}. | |
| 433 | |
| 434 @cindex preprocessing tokens | |
| 435 @cindex preprocessing numbers | |
| 436 @item | |
| 437 GCC complains about program fragments such as @samp{0x74ae-0x4000} | |
| 438 which appear to be two hexadecimal constants separated by the minus | |
| 439 operator. Actually, this string is a single @dfn{preprocessing token}. | |
| 440 Each such token must correspond to one token in C@. Since this does not, | |
| 441 GCC prints an error message. Although it may appear obvious that what | |
| 442 is meant is an operator and two values, the ISO C standard specifically | |
| 443 requires that this be treated as erroneous. | |
| 444 | |
| 445 A @dfn{preprocessing token} is a @dfn{preprocessing number} if it | |
| 446 begins with a digit and is followed by letters, underscores, digits, | |
| 447 periods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, | |
|
63
b7f97abdc517
update gcc from gcc-4.5.0 to gcc-4.6
ryoma <e075725@ie.u-ryukyu.ac.jp>
parents:
55
diff
changeset
|
448 @samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C90 |
| 0 | 449 mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot |
| 450 appear in preprocessing numbers.) | |
| 451 | |
| 452 To make the above program fragment valid, place whitespace in front of | |
| 453 the minus sign. This whitespace will end the preprocessing number. | |
| 454 @end itemize | |
| 455 | |
| 456 @node Fixed Headers | |
| 457 @section Fixed Header Files | |
| 458 | |
| 459 GCC needs to install corrected versions of some system header files. | |
| 460 This is because most target systems have some header files that won't | |
| 461 work with GCC unless they are changed. Some have bugs, some are | |
| 462 incompatible with ISO C, and some depend on special features of other | |
| 463 compilers. | |
| 464 | |
| 465 Installing GCC automatically creates and installs the fixed header | |
| 466 files, by running a program called @code{fixincludes}. Normally, you | |
| 467 don't need to pay attention to this. But there are cases where it | |
| 468 doesn't do the right thing automatically. | |
| 469 | |
| 470 @itemize @bullet | |
| 471 @item | |
| 472 If you update the system's header files, such as by installing a new | |
| 473 system version, the fixed header files of GCC are not automatically | |
| 474 updated. They can be updated using the @command{mkheaders} script | |
| 475 installed in | |
| 476 @file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. | |
| 477 | |
| 478 @item | |
| 479 On some systems, header file directories contain | |
| 480 machine-specific symbolic links in certain places. This makes it | |
| 481 possible to share most of the header files among hosts running the | |
| 482 same version of the system on different machine models. | |
| 483 | |
| 484 The programs that fix the header files do not understand this special | |
| 485 way of using symbolic links; therefore, the directory of fixed header | |
| 486 files is good only for the machine model used to build it. | |
| 487 | |
| 488 It is possible to make separate sets of fixed header files for the | |
| 489 different machine models, and arrange a structure of symbolic links so | |
| 490 as to use the proper set, but you'll have to do this by hand. | |
| 491 @end itemize | |
| 492 | |
| 493 @node Standard Libraries | |
| 494 @section Standard Libraries | |
| 495 | |
| 496 @opindex Wall | |
| 497 GCC by itself attempts to be a conforming freestanding implementation. | |
| 498 @xref{Standards,,Language Standards Supported by GCC}, for details of | |
| 499 what this means. Beyond the library facilities required of such an | |
| 500 implementation, the rest of the C library is supplied by the vendor of | |
| 501 the operating system. If that C library doesn't conform to the C | |
| 502 standards, then your programs might get warnings (especially when using | |
| 503 @option{-Wall}) that you don't expect. | |
| 504 | |
| 505 For example, the @code{sprintf} function on SunOS 4.1.3 returns | |
| 506 @code{char *} while the C standard says that @code{sprintf} returns an | |
| 507 @code{int}. The @code{fixincludes} program could make the prototype for | |
| 508 this function match the Standard, but that would be wrong, since the | |
| 509 function will still return @code{char *}. | |
| 510 | |
| 511 If you need a Standard compliant library, then you need to find one, as | |
| 512 GCC does not provide one. The GNU C library (called @code{glibc}) | |
| 513 provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for | |
| 514 GNU/Linux and HURD-based GNU systems; no recent version of it supports | |
| 515 other systems, though some very old versions did. Version 2.2 of the | |
| 516 GNU C library includes nearly complete C99 support. You could also ask | |
| 517 your operating system vendor if newer libraries are available. | |
| 518 | |
| 519 @node Disappointments | |
| 520 @section Disappointments and Misunderstandings | |
| 521 | |
| 522 These problems are perhaps regrettable, but we don't know any practical | |
| 523 way around them. | |
| 524 | |
| 525 @itemize @bullet | |
| 526 @item | |
| 527 Certain local variables aren't recognized by debuggers when you compile | |
| 528 with optimization. | |
| 529 | |
| 530 This occurs because sometimes GCC optimizes the variable out of | |
| 531 existence. There is no way to tell the debugger how to compute the | |
| 532 value such a variable ``would have had'', and it is not clear that would | |
| 533 be desirable anyway. So GCC simply does not mention the eliminated | |
| 534 variable when it writes debugging information. | |
| 535 | |
| 536 You have to expect a certain amount of disagreement between the | |
| 537 executable and your source code, when you use optimization. | |
| 538 | |
| 539 @cindex conflicting types | |
| 540 @cindex scope of declaration | |
| 541 @item | |
| 542 Users often think it is a bug when GCC reports an error for code | |
| 543 like this: | |
| 544 | |
| 545 @smallexample | |
| 546 int foo (struct mumble *); | |
| 547 | |
| 548 struct mumble @{ @dots{} @}; | |
| 549 | |
| 550 int foo (struct mumble *x) | |
| 551 @{ @dots{} @} | |
| 552 @end smallexample | |
| 553 | |
| 554 This code really is erroneous, because the scope of @code{struct | |
| 555 mumble} in the prototype is limited to the argument list containing it. | |
| 556 It does not refer to the @code{struct mumble} defined with file scope | |
| 557 immediately below---they are two unrelated types with similar names in | |
| 558 different scopes. | |
| 559 | |
| 560 But in the definition of @code{foo}, the file-scope type is used | |
| 561 because that is available to be inherited. Thus, the definition and | |
| 562 the prototype do not match, and you get an error. | |
| 563 | |
| 564 This behavior may seem silly, but it's what the ISO standard specifies. | |
| 565 It is easy enough for you to make your code work by moving the | |
| 566 definition of @code{struct mumble} above the prototype. It's not worth | |
| 567 being incompatible with ISO C just to avoid an error for the example | |
| 568 shown above. | |
| 569 | |
| 570 @item | |
| 571 Accesses to bit-fields even in volatile objects works by accessing larger | |
| 572 objects, such as a byte or a word. You cannot rely on what size of | |
| 573 object is accessed in order to read or write the bit-field; it may even | |
| 574 vary for a given bit-field according to the precise usage. | |
| 575 | |
| 576 If you care about controlling the amount of memory that is accessed, use | |
| 577 volatile but do not use bit-fields. | |
| 578 | |
| 579 @item | |
| 580 GCC comes with shell scripts to fix certain known problems in system | |
| 581 header files. They install corrected copies of various header files in | |
| 582 a special directory where only GCC will normally look for them. The | |
| 583 scripts adapt to various systems by searching all the system header | |
| 584 files for the problem cases that we know about. | |
| 585 | |
| 586 If new system header files are installed, nothing automatically arranges | |
| 587 to update the corrected header files. They can be updated using the | |
| 588 @command{mkheaders} script installed in | |
| 589 @file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. | |
| 590 | |
| 591 @item | |
| 592 @cindex floating point precision | |
| 593 On 68000 and x86 systems, for instance, you can get paradoxical results | |
| 594 if you test the precise values of floating point numbers. For example, | |
| 595 you can find that a floating point value which is not a NaN is not equal | |
| 596 to itself. This results from the fact that the floating point registers | |
| 597 hold a few more bits of precision than fit in a @code{double} in memory. | |
| 598 Compiled code moves values between memory and floating point registers | |
| 599 at its convenience, and moving them into memory truncates them. | |
| 600 | |
| 601 @opindex ffloat-store | |
| 602 You can partially avoid this problem by using the @option{-ffloat-store} | |
| 603 option (@pxref{Optimize Options}). | |
| 604 | |
| 605 @item | |
| 606 On AIX and other platforms without weak symbol support, templates | |
| 607 need to be instantiated explicitly and symbols for static members | |
| 608 of templates will not be generated. | |
| 609 | |
| 610 @item | |
| 611 On AIX, GCC scans object files and library archives for static | |
| 612 constructors and destructors when linking an application before the | |
| 613 linker prunes unreferenced symbols. This is necessary to prevent the | |
| 614 AIX linker from mistakenly assuming that static constructor or | |
| 615 destructor are unused and removing them before the scanning can occur. | |
| 616 All static constructors and destructors found will be referenced even | |
| 617 though the modules in which they occur may not be used by the program. | |
| 618 This may lead to both increased executable size and unexpected symbol | |
| 619 references. | |
| 620 @end itemize | |
| 621 | |
| 622 @node C++ Misunderstandings | |
| 623 @section Common Misunderstandings with GNU C++ | |
| 624 | |
| 625 @cindex misunderstandings in C++ | |
| 626 @cindex surprises in C++ | |
| 627 @cindex C++ misunderstandings | |
| 628 C++ is a complex language and an evolving one, and its standard | |
| 629 definition (the ISO C++ standard) was only recently completed. As a | |
| 630 result, your C++ compiler may occasionally surprise you, even when its | |
| 631 behavior is correct. This section discusses some areas that frequently | |
| 632 give rise to questions of this sort. | |
| 633 | |
| 634 @menu | |
| 635 * Static Definitions:: Static member declarations are not definitions | |
| 636 * Name lookup:: Name lookup, templates, and accessing members of base classes | |
| 637 * Temporaries:: Temporaries may vanish before you expect | |
| 638 * Copy Assignment:: Copy Assignment operators copy virtual bases twice | |
| 639 @end menu | |
| 640 | |
| 641 @node Static Definitions | |
| 642 @subsection Declare @emph{and} Define Static Members | |
| 643 | |
| 644 @cindex C++ static data, declaring and defining | |
| 645 @cindex static data in C++, declaring and defining | |
| 646 @cindex declaring static data in C++ | |
| 647 @cindex defining static data in C++ | |
| 648 When a class has static data members, it is not enough to @emph{declare} | |
| 649 the static member; you must also @emph{define} it. For example: | |
| 650 | |
| 651 @smallexample | |
| 652 class Foo | |
| 653 @{ | |
| 654 @dots{} | |
| 655 void method(); | |
| 656 static int bar; | |
| 657 @}; | |
| 658 @end smallexample | |
| 659 | |
| 660 This declaration only establishes that the class @code{Foo} has an | |
| 661 @code{int} named @code{Foo::bar}, and a member function named | |
| 662 @code{Foo::method}. But you still need to define @emph{both} | |
| 663 @code{method} and @code{bar} elsewhere. According to the ISO | |
| 664 standard, you must supply an initializer in one (and only one) source | |
| 665 file, such as: | |
| 666 | |
| 667 @smallexample | |
| 668 int Foo::bar = 0; | |
| 669 @end smallexample | |
| 670 | |
| 671 Other C++ compilers may not correctly implement the standard behavior. | |
| 672 As a result, when you switch to @command{g++} from one of these compilers, | |
| 673 you may discover that a program that appeared to work correctly in fact | |
| 674 does not conform to the standard: @command{g++} reports as undefined | |
| 675 symbols any static data members that lack definitions. | |
| 676 | |
| 677 | |
| 678 @node Name lookup | |
| 111 | 679 @subsection Name Lookup, Templates, and Accessing Members of Base Classes |
| 0 | 680 |
| 681 @cindex base class members | |
| 682 @cindex two-stage name lookup | |
| 683 @cindex dependent name lookup | |
| 684 | |
| 685 The C++ standard prescribes that all names that are not dependent on | |
| 686 template parameters are bound to their present definitions when parsing | |
| 687 a template function or class.@footnote{The C++ standard just uses the | |
| 688 term ``dependent'' for names that depend on the type or value of | |
| 689 template parameters. This shorter term will also be used in the rest of | |
| 690 this section.} Only names that are dependent are looked up at the point | |
| 691 of instantiation. For example, consider | |
| 692 | |
| 693 @smallexample | |
| 694 void foo(double); | |
| 695 | |
| 696 struct A @{ | |
| 697 template <typename T> | |
| 698 void f () @{ | |
| 699 foo (1); // @r{1} | |
| 700 int i = N; // @r{2} | |
| 701 T t; | |
| 702 t.bar(); // @r{3} | |
| 703 foo (t); // @r{4} | |
| 704 @} | |
| 705 | |
| 706 static const int N; | |
| 707 @}; | |
| 708 @end smallexample | |
| 709 | |
| 710 Here, the names @code{foo} and @code{N} appear in a context that does | |
| 711 not depend on the type of @code{T}. The compiler will thus require that | |
| 712 they are defined in the context of use in the template, not only before | |
| 713 the point of instantiation, and will here use @code{::foo(double)} and | |
| 714 @code{A::N}, respectively. In particular, it will convert the integer | |
| 715 value to a @code{double} when passing it to @code{::foo(double)}. | |
| 716 | |
| 717 Conversely, @code{bar} and the call to @code{foo} in the fourth marked | |
| 718 line are used in contexts that do depend on the type of @code{T}, so | |
| 719 they are only looked up at the point of instantiation, and you can | |
| 720 provide declarations for them after declaring the template, but before | |
| 721 instantiating it. In particular, if you instantiate @code{A::f<int>}, | |
| 722 the last line will call an overloaded @code{::foo(int)} if one was | |
| 723 provided, even if after the declaration of @code{struct A}. | |
| 724 | |
| 725 This distinction between lookup of dependent and non-dependent names is | |
| 726 called two-stage (or dependent) name lookup. G++ implements it | |
| 727 since version 3.4. | |
| 728 | |
| 729 Two-stage name lookup sometimes leads to situations with behavior | |
| 730 different from non-template codes. The most common is probably this: | |
| 731 | |
| 732 @smallexample | |
| 733 template <typename T> struct Base @{ | |
| 734 int i; | |
| 735 @}; | |
| 736 | |
| 737 template <typename T> struct Derived : public Base<T> @{ | |
| 738 int get_i() @{ return i; @} | |
| 739 @}; | |
| 740 @end smallexample | |
| 741 | |
| 742 In @code{get_i()}, @code{i} is not used in a dependent context, so the | |
| 743 compiler will look for a name declared at the enclosing namespace scope | |
| 744 (which is the global scope here). It will not look into the base class, | |
| 745 since that is dependent and you may declare specializations of | |
| 111 | 746 @code{Base} even after declaring @code{Derived}, so the compiler cannot |
| 0 | 747 really know what @code{i} would refer to. If there is no global |
| 748 variable @code{i}, then you will get an error message. | |
| 749 | |
| 750 In order to make it clear that you want the member of the base class, | |
| 751 you need to defer lookup until instantiation time, at which the base | |
| 752 class is known. For this, you need to access @code{i} in a dependent | |
| 753 context, by either using @code{this->i} (remember that @code{this} is of | |
| 754 type @code{Derived<T>*}, so is obviously dependent), or using | |
| 755 @code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought | |
| 756 into scope by a @code{using}-declaration. | |
| 757 | |
| 758 Another, similar example involves calling member functions of a base | |
| 759 class: | |
| 760 | |
| 761 @smallexample | |
| 762 template <typename T> struct Base @{ | |
| 763 int f(); | |
| 764 @}; | |
| 765 | |
| 766 template <typename T> struct Derived : Base<T> @{ | |
| 767 int g() @{ return f(); @}; | |
| 768 @}; | |
| 769 @end smallexample | |
| 770 | |
| 771 Again, the call to @code{f()} is not dependent on template arguments | |
| 772 (there are no arguments that depend on the type @code{T}, and it is also | |
| 773 not otherwise specified that the call should be in a dependent context). | |
| 774 Thus a global declaration of such a function must be available, since | |
| 775 the one in the base class is not visible until instantiation time. The | |
| 776 compiler will consequently produce the following error message: | |
| 777 | |
| 778 @smallexample | |
| 779 x.cc: In member function `int Derived<T>::g()': | |
| 780 x.cc:6: error: there are no arguments to `f' that depend on a template | |
| 781 parameter, so a declaration of `f' must be available | |
| 782 x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but | |
| 783 allowing the use of an undeclared name is deprecated) | |
| 784 @end smallexample | |
| 785 | |
| 786 To make the code valid either use @code{this->f()}, or | |
| 787 @code{Base<T>::f()}. Using the @option{-fpermissive} flag will also let | |
| 788 the compiler accept the code, by marking all function calls for which no | |
| 789 declaration is visible at the time of definition of the template for | |
| 790 later lookup at instantiation time, as if it were a dependent call. | |
| 791 We do not recommend using @option{-fpermissive} to work around invalid | |
| 792 code, and it will also only catch cases where functions in base classes | |
| 793 are called, not where variables in base classes are used (as in the | |
| 794 example above). | |
| 795 | |
| 796 Note that some compilers (including G++ versions prior to 3.4) get these | |
| 797 examples wrong and accept above code without an error. Those compilers | |
| 798 do not implement two-stage name lookup correctly. | |
| 799 | |
| 800 | |
| 801 @node Temporaries | |
| 802 @subsection Temporaries May Vanish Before You Expect | |
| 803 | |
| 804 @cindex temporaries, lifetime of | |
| 805 @cindex portions of temporary objects, pointers to | |
| 806 It is dangerous to use pointers or references to @emph{portions} of a | |
| 807 temporary object. The compiler may very well delete the object before | |
| 808 you expect it to, leaving a pointer to garbage. The most common place | |
| 809 where this problem crops up is in classes like string classes, | |
| 810 especially ones that define a conversion function to type @code{char *} | |
| 811 or @code{const char *}---which is one reason why the standard | |
| 812 @code{string} class requires you to call the @code{c_str} member | |
| 813 function. However, any class that returns a pointer to some internal | |
| 814 structure is potentially subject to this problem. | |
| 815 | |
| 816 For example, a program may use a function @code{strfunc} that returns | |
| 817 @code{string} objects, and another function @code{charfunc} that | |
| 818 operates on pointers to @code{char}: | |
| 819 | |
| 820 @smallexample | |
| 821 string strfunc (); | |
| 822 void charfunc (const char *); | |
| 823 | |
| 824 void | |
| 825 f () | |
| 826 @{ | |
| 827 const char *p = strfunc().c_str(); | |
| 828 @dots{} | |
| 829 charfunc (p); | |
| 830 @dots{} | |
| 831 charfunc (p); | |
| 832 @} | |
| 833 @end smallexample | |
| 834 | |
| 835 @noindent | |
| 836 In this situation, it may seem reasonable to save a pointer to the C | |
| 837 string returned by the @code{c_str} member function and use that rather | |
| 838 than call @code{c_str} repeatedly. However, the temporary string | |
| 839 created by the call to @code{strfunc} is destroyed after @code{p} is | |
| 840 initialized, at which point @code{p} is left pointing to freed memory. | |
| 841 | |
| 842 Code like this may run successfully under some other compilers, | |
| 843 particularly obsolete cfront-based compilers that delete temporaries | |
| 844 along with normal local variables. However, the GNU C++ behavior is | |
| 845 standard-conforming, so if your program depends on late destruction of | |
| 846 temporaries it is not portable. | |
| 847 | |
| 848 The safe way to write such code is to give the temporary a name, which | |
| 849 forces it to remain until the end of the scope of the name. For | |
| 850 example: | |
| 851 | |
| 852 @smallexample | |
| 853 const string& tmp = strfunc (); | |
| 854 charfunc (tmp.c_str ()); | |
| 855 @end smallexample | |
| 856 | |
| 857 @node Copy Assignment | |
| 858 @subsection Implicit Copy-Assignment for Virtual Bases | |
| 859 | |
| 860 When a base class is virtual, only one subobject of the base class | |
| 861 belongs to each full object. Also, the constructors and destructors are | |
| 862 invoked only once, and called from the most-derived class. However, such | |
| 863 objects behave unspecified when being assigned. For example: | |
| 864 | |
| 865 @smallexample | |
| 866 struct Base@{ | |
| 867 char *name; | |
| 868 Base(char *n) : name(strdup(n))@{@} | |
| 869 Base& operator= (const Base& other)@{ | |
| 870 free (name); | |
| 871 name = strdup (other.name); | |
| 872 @} | |
| 873 @}; | |
| 874 | |
| 875 struct A:virtual Base@{ | |
| 876 int val; | |
| 877 A():Base("A")@{@} | |
| 878 @}; | |
| 879 | |
| 880 struct B:virtual Base@{ | |
| 881 int bval; | |
| 882 B():Base("B")@{@} | |
| 883 @}; | |
| 884 | |
| 885 struct Derived:public A, public B@{ | |
| 886 Derived():Base("Derived")@{@} | |
| 887 @}; | |
| 888 | |
| 889 void func(Derived &d1, Derived &d2) | |
| 890 @{ | |
| 891 d1 = d2; | |
| 892 @} | |
| 893 @end smallexample | |
| 894 | |
| 895 The C++ standard specifies that @samp{Base::Base} is only called once | |
| 896 when constructing or copy-constructing a Derived object. It is | |
| 897 unspecified whether @samp{Base::operator=} is called more than once when | |
| 898 the implicit copy-assignment for Derived objects is invoked (as it is | |
| 899 inside @samp{func} in the example). | |
| 900 | |
| 901 G++ implements the ``intuitive'' algorithm for copy-assignment: assign all | |
| 902 direct bases, then assign all members. In that algorithm, the virtual | |
| 903 base subobject can be encountered more than once. In the example, copying | |
| 904 proceeds in the following order: @samp{val}, @samp{name} (via | |
| 905 @code{strdup}), @samp{bval}, and @samp{name} again. | |
| 906 | |
| 907 If application code relies on copy-assignment, a user-defined | |
| 908 copy-assignment operator removes any uncertainties. With such an | |
| 909 operator, the application can define whether and how the virtual base | |
| 910 subobject is assigned. | |
| 911 | |
| 912 @node Non-bugs | |
| 913 @section Certain Changes We Don't Want to Make | |
| 914 | |
| 915 This section lists changes that people frequently request, but which | |
| 916 we do not make because we think GCC is better without them. | |
| 917 | |
| 918 @itemize @bullet | |
| 919 @item | |
| 920 Checking the number and type of arguments to a function which has an | |
| 921 old-fashioned definition and no prototype. | |
| 922 | |
| 923 Such a feature would work only occasionally---only for calls that appear | |
| 924 in the same file as the called function, following the definition. The | |
| 925 only way to check all calls reliably is to add a prototype for the | |
| 926 function. But adding a prototype eliminates the motivation for this | |
| 927 feature. So the feature is not worthwhile. | |
| 928 | |
| 929 @item | |
| 930 Warning about using an expression whose type is signed as a shift count. | |
| 931 | |
| 932 Shift count operands are probably signed more often than unsigned. | |
| 933 Warning about this would cause far more annoyance than good. | |
| 934 | |
| 935 @item | |
| 936 Warning about assigning a signed value to an unsigned variable. | |
| 937 | |
| 938 Such assignments must be very common; warning about them would cause | |
| 939 more annoyance than good. | |
| 940 | |
| 941 @item | |
| 942 Warning when a non-void function value is ignored. | |
| 943 | |
| 944 C contains many standard functions that return a value that most | |
| 945 programs choose to ignore. One obvious example is @code{printf}. | |
| 946 Warning about this practice only leads the defensive programmer to | |
| 947 clutter programs with dozens of casts to @code{void}. Such casts are | |
| 948 required so frequently that they become visual noise. Writing those | |
| 949 casts becomes so automatic that they no longer convey useful | |
| 950 information about the intentions of the programmer. For functions | |
| 951 where the return value should never be ignored, use the | |
| 952 @code{warn_unused_result} function attribute (@pxref{Function | |
| 953 Attributes}). | |
| 954 | |
| 955 @item | |
| 956 @opindex fshort-enums | |
| 957 Making @option{-fshort-enums} the default. | |
| 958 | |
| 959 This would cause storage layout to be incompatible with most other C | |
| 960 compilers. And it doesn't seem very important, given that you can get | |
| 961 the same result in other ways. The case where it matters most is when | |
| 962 the enumeration-valued object is inside a structure, and in that case | |
| 963 you can specify a field width explicitly. | |
| 964 | |
| 965 @item | |
| 966 Making bit-fields unsigned by default on particular machines where ``the | |
| 967 ABI standard'' says to do so. | |
| 968 | |
| 969 The ISO C standard leaves it up to the implementation whether a bit-field | |
| 970 declared plain @code{int} is signed or not. This in effect creates two | |
| 971 alternative dialects of C@. | |
| 972 | |
| 973 @opindex fsigned-bitfields | |
| 974 @opindex funsigned-bitfields | |
| 975 The GNU C compiler supports both dialects; you can specify the signed | |
| 976 dialect with @option{-fsigned-bitfields} and the unsigned dialect with | |
| 977 @option{-funsigned-bitfields}. However, this leaves open the question of | |
| 978 which dialect to use by default. | |
| 979 | |
| 980 Currently, the preferred dialect makes plain bit-fields signed, because | |
| 981 this is simplest. Since @code{int} is the same as @code{signed int} in | |
| 982 every other context, it is cleanest for them to be the same in bit-fields | |
| 983 as well. | |
| 984 | |
| 985 Some computer manufacturers have published Application Binary Interface | |
| 986 standards which specify that plain bit-fields should be unsigned. It is | |
| 987 a mistake, however, to say anything about this issue in an ABI@. This is | |
| 988 because the handling of plain bit-fields distinguishes two dialects of C@. | |
| 989 Both dialects are meaningful on every type of machine. Whether a | |
| 990 particular object file was compiled using signed bit-fields or unsigned | |
| 991 is of no concern to other object files, even if they access the same | |
| 992 bit-fields in the same data structures. | |
| 993 | |
| 994 A given program is written in one or the other of these two dialects. | |
| 995 The program stands a chance to work on most any machine if it is | |
| 996 compiled with the proper dialect. It is unlikely to work at all if | |
| 997 compiled with the wrong dialect. | |
| 998 | |
| 999 Many users appreciate the GNU C compiler because it provides an | |
| 1000 environment that is uniform across machines. These users would be | |
| 1001 inconvenienced if the compiler treated plain bit-fields differently on | |
| 1002 certain machines. | |
| 1003 | |
| 1004 Occasionally users write programs intended only for a particular machine | |
| 1005 type. On these occasions, the users would benefit if the GNU C compiler | |
| 1006 were to support by default the same dialect as the other compilers on | |
| 1007 that machine. But such applications are rare. And users writing a | |
| 1008 program to run on more than one type of machine cannot possibly benefit | |
| 1009 from this kind of compatibility. | |
| 1010 | |
| 1011 This is why GCC does and will treat plain bit-fields in the same | |
| 1012 fashion on all types of machines (by default). | |
| 1013 | |
| 1014 There are some arguments for making bit-fields unsigned by default on all | |
| 1015 machines. If, for example, this becomes a universal de facto standard, | |
| 1016 it would make sense for GCC to go along with it. This is something | |
| 1017 to be considered in the future. | |
| 1018 | |
| 1019 (Of course, users strongly concerned about portability should indicate | |
| 1020 explicitly in each bit-field whether it is signed or not. In this way, | |
| 1021 they write programs which have the same meaning in both C dialects.) | |
| 1022 | |
| 1023 @item | |
| 1024 @opindex ansi | |
| 1025 @opindex std | |
| 1026 Undefining @code{__STDC__} when @option{-ansi} is not used. | |
| 1027 | |
| 1028 Currently, GCC defines @code{__STDC__} unconditionally. This provides | |
| 1029 good results in practice. | |
| 1030 | |
| 1031 Programmers normally use conditionals on @code{__STDC__} to ask whether | |
| 1032 it is safe to use certain features of ISO C, such as function | |
| 1033 prototypes or ISO token concatenation. Since plain @command{gcc} supports | |
| 1034 all the features of ISO C, the correct answer to these questions is | |
| 1035 ``yes''. | |
| 1036 | |
| 1037 Some users try to use @code{__STDC__} to check for the availability of | |
| 1038 certain library facilities. This is actually incorrect usage in an ISO | |
| 1039 C program, because the ISO C standard says that a conforming | |
| 1040 freestanding implementation should define @code{__STDC__} even though it | |
| 1041 does not have the library facilities. @samp{gcc -ansi -pedantic} is a | |
| 1042 conforming freestanding implementation, and it is therefore required to | |
| 1043 define @code{__STDC__}, even though it does not come with an ISO C | |
| 1044 library. | |
| 1045 | |
| 1046 Sometimes people say that defining @code{__STDC__} in a compiler that | |
| 1047 does not completely conform to the ISO C standard somehow violates the | |
| 1048 standard. This is illogical. The standard is a standard for compilers | |
| 1049 that claim to support ISO C, such as @samp{gcc -ansi}---not for other | |
| 1050 compilers such as plain @command{gcc}. Whatever the ISO C standard says | |
| 1051 is relevant to the design of plain @command{gcc} without @option{-ansi} only | |
| 1052 for pragmatic reasons, not as a requirement. | |
| 1053 | |
| 1054 GCC normally defines @code{__STDC__} to be 1, and in addition | |
| 1055 defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, | |
| 1056 or a @option{-std} option for strict conformance to some version of ISO C@. | |
| 1057 On some hosts, system include files use a different convention, where | |
| 1058 @code{__STDC__} is normally 0, but is 1 if the user specifies strict | |
| 1059 conformance to the C Standard. GCC follows the host convention when | |
| 1060 processing system include files, but when processing user files it follows | |
| 1061 the usual GNU C convention. | |
| 1062 | |
| 1063 @item | |
| 1064 Undefining @code{__STDC__} in C++. | |
| 1065 | |
| 1066 Programs written to compile with C++-to-C translators get the | |
| 1067 value of @code{__STDC__} that goes with the C compiler that is | |
| 1068 subsequently used. These programs must test @code{__STDC__} | |
| 1069 to determine what kind of C preprocessor that compiler uses: | |
| 1070 whether they should concatenate tokens in the ISO C fashion | |
| 1071 or in the traditional fashion. | |
| 1072 | |
| 1073 These programs work properly with GNU C++ if @code{__STDC__} is defined. | |
| 1074 They would not work otherwise. | |
| 1075 | |
| 1076 In addition, many header files are written to provide prototypes in ISO | |
| 1077 C but not in traditional C@. Many of these header files can work without | |
| 1078 change in C++ provided @code{__STDC__} is defined. If @code{__STDC__} | |
| 1079 is not defined, they will all fail, and will all need to be changed to | |
| 1080 test explicitly for C++ as well. | |
| 1081 | |
| 1082 @item | |
| 1083 Deleting ``empty'' loops. | |
| 1084 | |
| 1085 Historically, GCC has not deleted ``empty'' loops under the | |
| 1086 assumption that the most likely reason you would put one in a program is | |
| 1087 to have a delay, so deleting them will not make real programs run any | |
| 1088 faster. | |
| 1089 | |
| 1090 However, the rationale here is that optimization of a nonempty loop | |
| 1091 cannot produce an empty one. This held for carefully written C compiled | |
| 1092 with less powerful optimizers but is not always the case for carefully | |
| 1093 written C++ or with more powerful optimizers. | |
| 1094 Thus GCC will remove operations from loops whenever it can determine | |
| 1095 those operations are not externally visible (apart from the time taken | |
| 1096 to execute them, of course). In case the loop can be proved to be finite, | |
| 1097 GCC will also remove the loop itself. | |
| 1098 | |
| 1099 Be aware of this when performing timing tests, for instance the | |
| 1100 following loop can be completely removed, provided | |
| 1101 @code{some_expression} can provably not change any global state. | |
| 1102 | |
| 1103 @smallexample | |
| 1104 @{ | |
| 1105 int sum = 0; | |
| 1106 int ix; | |
| 1107 | |
| 1108 for (ix = 0; ix != 10000; ix++) | |
| 1109 sum += some_expression; | |
| 1110 @} | |
| 1111 @end smallexample | |
| 1112 | |
| 1113 Even though @code{sum} is accumulated in the loop, no use is made of | |
| 1114 that summation, so the accumulation can be removed. | |
| 1115 | |
| 1116 @item | |
| 1117 Making side effects happen in the same order as in some other compiler. | |
| 1118 | |
| 1119 @cindex side effects, order of evaluation | |
| 1120 @cindex order of evaluation, side effects | |
| 1121 It is never safe to depend on the order of evaluation of side effects. | |
| 1122 For example, a function call like this may very well behave differently | |
| 1123 from one compiler to another: | |
| 1124 | |
| 1125 @smallexample | |
| 1126 void func (int, int); | |
| 1127 | |
| 1128 int i = 2; | |
| 1129 func (i++, i++); | |
| 1130 @end smallexample | |
| 1131 | |
| 1132 There is no guarantee (in either the C or the C++ standard language | |
| 1133 definitions) that the increments will be evaluated in any particular | |
| 1134 order. Either increment might happen first. @code{func} might get the | |
| 1135 arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. | |
| 1136 | |
| 1137 @item | |
| 1138 Making certain warnings into errors by default. | |
| 1139 | |
| 1140 Some ISO C testsuites report failure when the compiler does not produce | |
| 1141 an error message for a certain program. | |
| 1142 | |
| 1143 @opindex pedantic-errors | |
| 1144 ISO C requires a ``diagnostic'' message for certain kinds of invalid | |
| 1145 programs, but a warning is defined by GCC to count as a diagnostic. If | |
| 1146 GCC produces a warning but not an error, that is correct ISO C support. | |
| 1147 If testsuites call this ``failure'', they should be run with the GCC | |
| 1148 option @option{-pedantic-errors}, which will turn these warnings into | |
| 1149 errors. | |
| 1150 | |
| 1151 @end itemize | |
| 1152 | |
| 1153 @node Warnings and Errors | |
| 1154 @section Warning Messages and Error Messages | |
| 1155 | |
| 1156 @cindex error messages | |
| 1157 @cindex warnings vs errors | |
| 1158 @cindex messages, warning and error | |
| 1159 The GNU compiler can produce two kinds of diagnostics: errors and | |
| 1160 warnings. Each kind has a different purpose: | |
| 1161 | |
| 1162 @itemize @w{} | |
| 1163 @item | |
| 1164 @dfn{Errors} report problems that make it impossible to compile your | |
| 1165 program. GCC reports errors with the source file name and line | |
| 1166 number where the problem is apparent. | |
| 1167 | |
| 1168 @item | |
| 1169 @dfn{Warnings} report other unusual conditions in your code that | |
| 1170 @emph{may} indicate a problem, although compilation can (and does) | |
| 1171 proceed. Warning messages also report the source file name and line | |
| 1172 number, but include the text @samp{warning:} to distinguish them | |
| 1173 from error messages. | |
| 1174 @end itemize | |
| 1175 | |
| 1176 Warnings may indicate danger points where you should check to make sure | |
| 1177 that your program really does what you intend; or the use of obsolete | |
| 1178 features; or the use of nonstandard features of GNU C or C++. Many | |
| 1179 warnings are issued only if you ask for them, with one of the @option{-W} | |
| 1180 options (for instance, @option{-Wall} requests a variety of useful | |
| 1181 warnings). | |
| 1182 | |
| 1183 @opindex pedantic | |
| 1184 @opindex pedantic-errors | |
| 1185 GCC always tries to compile your program if possible; it never | |
| 1186 gratuitously rejects a program whose meaning is clear merely because | |
| 1187 (for instance) it fails to conform to a standard. In some cases, | |
| 1188 however, the C and C++ standards specify that certain extensions are | |
| 1189 forbidden, and a diagnostic @emph{must} be issued by a conforming | |
| 1190 compiler. The @option{-pedantic} option tells GCC to issue warnings in | |
| 1191 such cases; @option{-pedantic-errors} says to make them errors instead. | |
| 1192 This does not mean that @emph{all} non-ISO constructs get warnings | |
| 1193 or errors. | |
| 1194 | |
| 1195 @xref{Warning Options,,Options to Request or Suppress Warnings}, for | |
| 1196 more detail on these and related command-line options. |