190075Sobrien@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 2132718Skan@c 1999, 2000, 2001, 2003, 2004 Free Software Foundation, Inc. 390075Sobrien@c This is part of the GCC manual. 490075Sobrien@c For copying conditions, see the file gcc.texi. 590075Sobrien 690075Sobrien@node Trouble 790075Sobrien@chapter Known Causes of Trouble with GCC 890075Sobrien@cindex bugs, known 990075Sobrien@cindex installation trouble 1090075Sobrien@cindex known causes of trouble 1190075Sobrien 1290075SobrienThis section describes known problems that affect users of GCC@. Most 1390075Sobrienof these are not GCC bugs per se---if they were, we would fix them. 1490075SobrienBut the result for a user may be like the result of a bug. 1590075Sobrien 1690075SobrienSome of these problems are due to bugs in other software, some are 1790075Sobrienmissing features that are too much work to add, and some are places 1890075Sobrienwhere people's opinions differ as to what is best. 1990075Sobrien 2090075Sobrien@menu 2190075Sobrien* Actual Bugs:: Bugs we will fix later. 2290075Sobrien* Cross-Compiler Problems:: Common problems of cross compiling with GCC. 2390075Sobrien* Interoperation:: Problems using GCC with other compilers, 2490075Sobrien and with certain linkers, assemblers and debuggers. 2590075Sobrien* Incompatibilities:: GCC is incompatible with traditional C. 2690075Sobrien* Fixed Headers:: GCC uses corrected versions of system header files. 2790075Sobrien This is necessary, but doesn't always work smoothly. 2890075Sobrien* Standard Libraries:: GCC uses the system C library, which might not be 2990075Sobrien compliant with the ISO C standard. 3090075Sobrien* Disappointments:: Regrettable things we can't change, but not quite bugs. 3190075Sobrien* C++ Misunderstandings:: Common misunderstandings with GNU C++. 3290075Sobrien* Protoize Caveats:: Things to watch out for when using @code{protoize}. 3390075Sobrien* Non-bugs:: Things we think are right, but some others disagree. 3490075Sobrien* Warnings and Errors:: Which problems in your code get warnings, 3590075Sobrien and which get errors. 3690075Sobrien@end menu 3790075Sobrien 3890075Sobrien@node Actual Bugs 3990075Sobrien@section Actual Bugs We Haven't Fixed Yet 4090075Sobrien 4190075Sobrien@itemize @bullet 4290075Sobrien@item 4390075SobrienThe @code{fixincludes} script interacts badly with automounters; if the 4490075Sobriendirectory of system header files is automounted, it tends to be 4590075Sobrienunmounted while @code{fixincludes} is running. This would seem to be a 4690075Sobrienbug in the automounter. We don't know any good way to work around it. 4790075Sobrien 4890075Sobrien@item 4990075SobrienThe @code{fixproto} script will sometimes add prototypes for the 5090075Sobrien@code{sigsetjmp} and @code{siglongjmp} functions that reference the 5190075Sobrien@code{jmp_buf} type before that type is defined. To work around this, 5290075Sobrienedit the offending file and place the typedef in front of the 5390075Sobrienprototypes. 5490075Sobrien@end itemize 5590075Sobrien 5690075Sobrien@node Cross-Compiler Problems 5790075Sobrien@section Cross-Compiler Problems 5890075Sobrien 5990075SobrienYou may run into problems with cross compilation on certain machines, 6090075Sobrienfor several reasons. 6190075Sobrien 6290075Sobrien@itemize @bullet 6390075Sobrien@item 6490075SobrienAt present, the program @file{mips-tfile} which adds debug 6590075Sobriensupport to object files on MIPS systems does not work in a cross 6690075Sobriencompile environment. 6790075Sobrien@end itemize 6890075Sobrien 6990075Sobrien@node Interoperation 7090075Sobrien@section Interoperation 7190075Sobrien 7290075SobrienThis section lists various difficulties encountered in using GCC 7390075Sobrientogether with other compilers or with the assemblers, linkers, 7490075Sobrienlibraries and debuggers on certain systems. 7590075Sobrien 7690075Sobrien@itemize @bullet 7790075Sobrien@item 78103445SkanOn many platforms, GCC supports a different ABI for C++ than do other 79103445Skancompilers, so the object files compiled by GCC cannot be used with object 80103445Skanfiles generated by another C++ compiler. 8190075Sobrien 82103445SkanAn area where the difference is most apparent is name mangling. The use 83103445Skanof different name mangling is intentional, to protect you from more subtle 84103445Skanproblems. 8590075SobrienCompilers differ as to many internal details of C++ implementation, 8690075Sobrienincluding: how class instances are laid out, how multiple inheritance is 8790075Sobrienimplemented, and how virtual function calls are handled. If the name 8890075Sobrienencoding were made the same, your programs would link against libraries 8990075Sobrienprovided from other compilers---but the programs would then crash when 9090075Sobrienrun. Incompatible libraries are then detected at link time, rather than 9190075Sobrienat run time. 9290075Sobrien 9390075Sobrien@item 9490075SobrienOn some BSD systems, including some versions of Ultrix, use of profiling 9590075Sobriencauses static variable destructors (currently used only in C++) not to 9690075Sobrienbe run. 9790075Sobrien 9890075Sobrien@item 9990075SobrienOn some SGI systems, when you use @option{-lgl_s} as an option, 10090075Sobrienit gets translated magically to @samp{-lgl_s -lX11_s -lc_s}. 10190075SobrienNaturally, this does not happen when you use GCC@. 10290075SobrienYou must specify all three options explicitly. 10390075Sobrien 10490075Sobrien@item 105117395SkanOn a SPARC, GCC aligns all values of type @code{double} on an 8-byte 10690075Sobrienboundary, and it expects every @code{double} to be so aligned. The Sun 10790075Sobriencompiler usually gives @code{double} values 8-byte alignment, with one 10890075Sobrienexception: function arguments of type @code{double} may not be aligned. 10990075Sobrien 11090075SobrienAs a result, if a function compiled with Sun CC takes the address of an 11190075Sobrienargument of type @code{double} and passes this pointer of type 11290075Sobrien@code{double *} to a function compiled with GCC, dereferencing the 11390075Sobrienpointer may cause a fatal signal. 11490075Sobrien 11590075SobrienOne way to solve this problem is to compile your entire program with GCC@. 11690075SobrienAnother solution is to modify the function that is compiled with 11790075SobrienSun CC to copy the argument into a local variable; local variables 11890075Sobrienare always properly aligned. A third solution is to modify the function 11990075Sobrienthat uses the pointer to dereference it via the following function 12090075Sobrien@code{access_double} instead of directly with @samp{*}: 12190075Sobrien 12290075Sobrien@smallexample 12390075Sobrieninline double 12490075Sobrienaccess_double (double *unaligned_ptr) 12590075Sobrien@{ 12690075Sobrien union d2i @{ double d; int i[2]; @}; 12790075Sobrien 12890075Sobrien union d2i *p = (union d2i *) unaligned_ptr; 12990075Sobrien union d2i u; 13090075Sobrien 13190075Sobrien u.i[0] = p->i[0]; 13290075Sobrien u.i[1] = p->i[1]; 13390075Sobrien 13490075Sobrien return u.d; 13590075Sobrien@} 13690075Sobrien@end smallexample 13790075Sobrien 13890075Sobrien@noindent 13990075SobrienStoring into the pointer can be done likewise with the same union. 14090075Sobrien 14190075Sobrien@item 14290075SobrienOn Solaris, the @code{malloc} function in the @file{libmalloc.a} library 14390075Sobrienmay allocate memory that is only 4 byte aligned. Since GCC on the 144117395SkanSPARC assumes that doubles are 8 byte aligned, this may result in a 14590075Sobrienfatal signal if doubles are stored in memory allocated by the 14690075Sobrien@file{libmalloc.a} library. 14790075Sobrien 14890075SobrienThe solution is to not use the @file{libmalloc.a} library. Use instead 14990075Sobrien@code{malloc} and related functions from @file{libc.a}; they do not have 15090075Sobrienthis problem. 15190075Sobrien 15290075Sobrien@item 15390075SobrienOn the HP PA machine, ADB sometimes fails to work on functions compiled 15490075Sobrienwith GCC@. Specifically, it fails to work on functions that use 15590075Sobrien@code{alloca} or variable-size arrays. This is because GCC doesn't 15690075Sobriengenerate HP-UX unwind descriptors for such functions. It may even be 15790075Sobrienimpossible to generate them. 15890075Sobrien 15990075Sobrien@item 16090075SobrienDebugging (@option{-g}) is not supported on the HP PA machine, unless you use 16190075Sobrienthe preliminary GNU tools. 16290075Sobrien 16390075Sobrien@item 16490075SobrienTaking the address of a label may generate errors from the HP-UX 16590075SobrienPA assembler. GAS for the PA does not have this problem. 16690075Sobrien 16790075Sobrien@item 16890075SobrienUsing floating point parameters for indirect calls to static functions 16990075Sobrienwill not work when using the HP assembler. There simply is no way for GCC 17090075Sobriento specify what registers hold arguments for static functions when using 17190075Sobrienthe HP assembler. GAS for the PA does not have this problem. 17290075Sobrien 17390075Sobrien@item 17490075SobrienIn extremely rare cases involving some very large functions you may 17590075Sobrienreceive errors from the HP linker complaining about an out of bounds 17690075Sobrienunconditional branch offset. This used to occur more often in previous 17790075Sobrienversions of GCC, but is now exceptionally rare. If you should run 17890075Sobrieninto it, you can work around by making your function smaller. 17990075Sobrien 18090075Sobrien@item 18190075SobrienGCC compiled code sometimes emits warnings from the HP-UX assembler of 18290075Sobrienthe form: 18390075Sobrien 18490075Sobrien@smallexample 18590075Sobrien(warning) Use of GR3 when 18690075Sobrien frame >= 8192 may cause conflict. 18790075Sobrien@end smallexample 18890075Sobrien 18990075SobrienThese warnings are harmless and can be safely ignored. 19090075Sobrien 19190075Sobrien@item 19290075SobrienIn extremely rare cases involving some very large functions you may 19390075Sobrienreceive errors from the AIX Assembler complaining about a displacement 19490075Sobrienthat is too large. If you should run into it, you can work around by 19590075Sobrienmaking your function smaller. 19690075Sobrien 19790075Sobrien@item 19890075SobrienThe @file{libstdc++.a} library in GCC relies on the SVR4 dynamic 19990075Sobrienlinker semantics which merges global symbols between libraries and 20090075Sobrienapplications, especially necessary for C++ streams functionality. 20190075SobrienThis is not the default behavior of AIX shared libraries and dynamic 20290075Sobrienlinking. @file{libstdc++.a} is built on AIX with ``runtime-linking'' 20390075Sobrienenabled so that symbol merging can occur. To utilize this feature, 20490075Sobrienthe application linked with @file{libstdc++.a} must include the 20590075Sobrien@option{-Wl,-brtl} flag on the link line. G++ cannot impose this 20690075Sobrienbecause this option may interfere with the semantics of the user 20790075Sobrienprogram and users may not always use @samp{g++} to link his or her 208169689Skanapplication. Applications are not required to use the 20990075Sobrien@option{-Wl,-brtl} flag on the link line---the rest of the 21090075Sobrien@file{libstdc++.a} library which is not dependent on the symbol 21190075Sobrienmerging semantics will continue to function correctly. 21290075Sobrien 21390075Sobrien@item 21490075SobrienAn application can interpose its own definition of functions for 21590075Sobrienfunctions invoked by @file{libstdc++.a} with ``runtime-linking'' 216169689Skanenabled on AIX@. To accomplish this the application must be linked 21790075Sobrienwith ``runtime-linking'' option and the functions explicitly must be 21890075Sobrienexported by the application (@option{-Wl,-brtl,-bE:exportfile}). 21990075Sobrien 22090075Sobrien@item 22190075SobrienAIX on the RS/6000 provides support (NLS) for environments outside of 22290075Sobrienthe United States. Compilers and assemblers use NLS to support 22390075Sobrienlocale-specific representations of various objects including 22490075Sobrienfloating-point numbers (@samp{.} vs @samp{,} for separating decimal 225169689Skanfractions). There have been problems reported where the library linked 22690075Sobrienwith GCC does not produce the same floating-point formats that the 227169689Skanassembler accepts. If you have this problem, set the @env{LANG} 22890075Sobrienenvironment variable to @samp{C} or @samp{En_US}. 22990075Sobrien 23090075Sobrien@item 23190075Sobrien@opindex fdollars-in-identifiers 23290075SobrienEven if you specify @option{-fdollars-in-identifiers}, 23390075Sobrienyou cannot successfully use @samp{$} in identifiers on the RS/6000 due 23490075Sobriento a restriction in the IBM assembler. GAS supports these 23590075Sobrienidentifiers. 23690075Sobrien 23790075Sobrien@cindex VAX calling convention 23890075Sobrien@cindex Ultrix calling convention 23990075Sobrien@item 24090075Sobrien@opindex fcall-saved 24190075SobrienOn Ultrix, the Fortran compiler expects registers 2 through 5 to be saved 24290075Sobrienby function calls. However, the C compiler uses conventions compatible 24390075Sobrienwith BSD Unix: registers 2 through 5 may be clobbered by function calls. 24490075Sobrien 24590075SobrienGCC uses the same convention as the Ultrix C compiler. You can use 24690075Sobrienthese options to produce code compatible with the Fortran compiler: 24790075Sobrien 24890075Sobrien@smallexample 24990075Sobrien-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 25090075Sobrien@end smallexample 25190075Sobrien@end itemize 25290075Sobrien 25390075Sobrien@node Incompatibilities 25490075Sobrien@section Incompatibilities of GCC 25590075Sobrien@cindex incompatibilities of GCC 25690075Sobrien@opindex traditional 25790075Sobrien 25890075SobrienThere are several noteworthy incompatibilities between GNU C and K&R 259117395Skan(non-ISO) versions of C@. 26090075Sobrien 26190075Sobrien@itemize @bullet 26290075Sobrien@cindex string constants 26390075Sobrien@cindex read-only strings 26490075Sobrien@cindex shared strings 26590075Sobrien@item 26690075SobrienGCC normally makes string constants read-only. If several 26790075Sobrienidentical-looking string constants are used, GCC stores only one 26890075Sobriencopy of the string. 26990075Sobrien 27090075Sobrien@cindex @code{mktemp}, and constant strings 27190075SobrienOne consequence is that you cannot call @code{mktemp} with a string 27290075Sobrienconstant argument. The function @code{mktemp} always alters the 27390075Sobrienstring its argument points to. 27490075Sobrien 27590075Sobrien@cindex @code{sscanf}, and constant strings 27690075Sobrien@cindex @code{fscanf}, and constant strings 27790075Sobrien@cindex @code{scanf}, and constant strings 278169689SkanAnother consequence is that @code{sscanf} does not work on some very 279169689Skanold systems when passed a string constant as its format control string 280169689Skanor input. This is because @code{sscanf} incorrectly tries to write 281169689Skaninto the string constant. Likewise @code{fscanf} and @code{scanf}. 28290075Sobrien 283169689SkanThe solution to these problems is to change the program to use 28490075Sobrien@code{char}-array variables with initialization strings for these 285169689Skanpurposes instead of string constants. 28690075Sobrien 28790075Sobrien@item 28890075Sobrien@code{-2147483648} is positive. 28990075Sobrien 29090075SobrienThis is because 2147483648 cannot fit in the type @code{int}, so 29190075Sobrien(following the ISO C rules) its data type is @code{unsigned long int}. 29290075SobrienNegating this value yields 2147483648 again. 29390075Sobrien 29490075Sobrien@item 29590075SobrienGCC does not substitute macro arguments when they appear inside of 29690075Sobrienstring constants. For example, the following macro in GCC 29790075Sobrien 298132718Skan@smallexample 29990075Sobrien#define foo(a) "a" 300132718Skan@end smallexample 30190075Sobrien 30290075Sobrien@noindent 30390075Sobrienwill produce output @code{"a"} regardless of what the argument @var{a} is. 30490075Sobrien 30590075Sobrien@cindex @code{setjmp} incompatibilities 30690075Sobrien@cindex @code{longjmp} incompatibilities 30790075Sobrien@item 30890075SobrienWhen you use @code{setjmp} and @code{longjmp}, the only automatic 30990075Sobrienvariables guaranteed to remain valid are those declared 31090075Sobrien@code{volatile}. This is a consequence of automatic register 31190075Sobrienallocation. Consider this function: 31290075Sobrien 313132718Skan@smallexample 31490075Sobrienjmp_buf j; 31590075Sobrien 31690075Sobrienfoo () 31790075Sobrien@{ 31890075Sobrien int a, b; 31990075Sobrien 32090075Sobrien a = fun1 (); 32190075Sobrien if (setjmp (j)) 32290075Sobrien return a; 32390075Sobrien 32490075Sobrien a = fun2 (); 32590075Sobrien /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */ 32690075Sobrien return a + fun3 (); 32790075Sobrien@} 328132718Skan@end smallexample 32990075Sobrien 33090075SobrienHere @code{a} may or may not be restored to its first value when the 33190075Sobrien@code{longjmp} occurs. If @code{a} is allocated in a register, then 33290075Sobrienits first value is restored; otherwise, it keeps the last value stored 33390075Sobrienin it. 33490075Sobrien 33590075Sobrien@opindex W 33690075SobrienIf you use the @option{-W} option with the @option{-O} option, you will 33790075Sobrienget a warning when GCC thinks such a problem might be possible. 33890075Sobrien 33990075Sobrien@item 34090075SobrienPrograms that use preprocessing directives in the middle of macro 34190075Sobrienarguments do not work with GCC@. For example, a program like this 34290075Sobrienwill not work: 34390075Sobrien 344132718Skan@smallexample 34590075Sobrien@group 34690075Sobrienfoobar ( 34790075Sobrien#define luser 34890075Sobrien hack) 34990075Sobrien@end group 350132718Skan@end smallexample 35190075Sobrien 352117395SkanISO C does not permit such a construct. 35390075Sobrien 35490075Sobrien@item 35590075SobrienK&R compilers allow comments to cross over an inclusion boundary 356132718Skan(i.e.@: started in an include file and ended in the including file). 35790075Sobrien 35890075Sobrien@cindex external declaration scope 35990075Sobrien@cindex scope of external declarations 36090075Sobrien@cindex declaration scope 36190075Sobrien@item 36290075SobrienDeclarations of external variables and functions within a block apply 36390075Sobrienonly to the block containing the declaration. In other words, they 36490075Sobrienhave the same scope as any other declaration in the same place. 36590075Sobrien 36690075SobrienIn some other C compilers, a @code{extern} declaration affects all the 36790075Sobrienrest of the file even if it happens within a block. 36890075Sobrien 36990075Sobrien@item 37090075SobrienIn traditional C, you can combine @code{long}, etc., with a typedef name, 37190075Sobrienas shown here: 37290075Sobrien 373132718Skan@smallexample 37490075Sobrientypedef int foo; 37590075Sobrientypedef long foo bar; 376132718Skan@end smallexample 37790075Sobrien 37890075SobrienIn ISO C, this is not allowed: @code{long} and other type modifiers 379117395Skanrequire an explicit @code{int}. 38090075Sobrien 38190075Sobrien@cindex typedef names as function parameters 38290075Sobrien@item 383117395SkanPCC allows typedef names to be used as function parameters. 38490075Sobrien 38590075Sobrien@item 386117395SkanTraditional C allows the following erroneous pair of declarations to 387117395Skanappear together in a given scope: 38890075Sobrien 389132718Skan@smallexample 39090075Sobrientypedef int foo; 39190075Sobrientypedef foo foo; 392132718Skan@end smallexample 39390075Sobrien 39490075Sobrien@item 395117395SkanGCC treats all characters of identifiers as significant. According to 396117395SkanK&R-1 (2.2), ``No more than the first eight characters are significant, 397117395Skanalthough more may be used.''. Also according to K&R-1 (2.2), ``An 398117395Skanidentifier is a sequence of letters and digits; the first character must 399117395Skanbe a letter. The underscore _ counts as a letter.'', but GCC also 400117395Skanallows dollar signs in identifiers. 40190075Sobrien 40290075Sobrien@cindex whitespace 40390075Sobrien@item 40490075SobrienPCC allows whitespace in the middle of compound assignment operators 40590075Sobriensuch as @samp{+=}. GCC, following the ISO standard, does not 406117395Skanallow this. 40790075Sobrien 40890075Sobrien@cindex apostrophes 40990075Sobrien@cindex ' 41090075Sobrien@item 41190075SobrienGCC complains about unterminated character constants inside of 41290075Sobrienpreprocessing conditionals that fail. Some programs have English 41390075Sobriencomments enclosed in conditionals that are guaranteed to fail; if these 41490075Sobriencomments contain apostrophes, GCC will probably report an error. For 41590075Sobrienexample, this code would produce an error: 41690075Sobrien 417132718Skan@smallexample 41890075Sobrien#if 0 41990075SobrienYou can't expect this to work. 42090075Sobrien#endif 421132718Skan@end smallexample 42290075Sobrien 42390075SobrienThe best solution to such a problem is to put the text into an actual 424117395SkanC comment delimited by @samp{/*@dots{}*/}. 42590075Sobrien 42690075Sobrien@item 42790075SobrienMany user programs contain the declaration @samp{long time ();}. In the 42890075Sobrienpast, the system header files on many systems did not actually declare 42990075Sobrien@code{time}, so it did not matter what type your program declared it to 43090075Sobrienreturn. But in systems with ISO C headers, @code{time} is declared to 43190075Sobrienreturn @code{time_t}, and if that is not the same as @code{long}, then 43290075Sobrien@samp{long time ();} is erroneous. 43390075Sobrien 43490075SobrienThe solution is to change your program to use appropriate system headers 43590075Sobrien(@code{<time.h>} on systems with ISO C headers) and not to declare 43690075Sobrien@code{time} if the system header files declare it, or failing that to 43790075Sobrienuse @code{time_t} as the return type of @code{time}. 43890075Sobrien 43990075Sobrien@cindex @code{float} as function value type 44090075Sobrien@item 44190075SobrienWhen compiling functions that return @code{float}, PCC converts it to 44290075Sobriena double. GCC actually returns a @code{float}. If you are concerned 44390075Sobrienwith PCC compatibility, you should declare your functions to return 44490075Sobrien@code{double}; you might as well say what you mean. 44590075Sobrien 44690075Sobrien@cindex structures 44790075Sobrien@cindex unions 44890075Sobrien@item 44990075SobrienWhen compiling functions that return structures or unions, GCC 45090075Sobrienoutput code normally uses a method different from that used on most 45190075Sobrienversions of Unix. As a result, code compiled with GCC cannot call 45290075Sobriena structure-returning function compiled with PCC, and vice versa. 45390075Sobrien 45490075SobrienThe method used by GCC is as follows: a structure or union which is 45590075Sobrien1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union 45690075Sobrienwith any other size is stored into an address supplied by the caller 45790075Sobrien(usually in a special, fixed register, but on some machines it is passed 458132718Skanon the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX} 459132718Skantells GCC where to pass this address. 46090075Sobrien 46190075SobrienBy contrast, PCC on most target machines returns structures and unions 46290075Sobrienof any size by copying the data into an area of static storage, and then 46390075Sobrienreturning the address of that storage as if it were a pointer value. 46490075SobrienThe caller must copy the data from that memory area to the place where 46590075Sobrienthe value is wanted. GCC does not use this method because it is 46690075Sobrienslower and nonreentrant. 46790075Sobrien 46890075SobrienOn some newer machines, PCC uses a reentrant convention for all 46990075Sobrienstructure and union returning. GCC on most of these machines uses a 47090075Sobriencompatible convention when returning structures and unions in memory, 47190075Sobrienbut still returns small structures and unions in registers. 47290075Sobrien 47390075Sobrien@opindex fpcc-struct-return 47490075SobrienYou can tell GCC to use a compatible convention for all structure and 47590075Sobrienunion returning with the option @option{-fpcc-struct-return}. 47690075Sobrien 47790075Sobrien@cindex preprocessing tokens 47890075Sobrien@cindex preprocessing numbers 47990075Sobrien@item 48090075SobrienGCC complains about program fragments such as @samp{0x74ae-0x4000} 48190075Sobrienwhich appear to be two hexadecimal constants separated by the minus 48290075Sobrienoperator. Actually, this string is a single @dfn{preprocessing token}. 48390075SobrienEach such token must correspond to one token in C@. Since this does not, 48490075SobrienGCC prints an error message. Although it may appear obvious that what 48590075Sobrienis meant is an operator and two values, the ISO C standard specifically 48690075Sobrienrequires that this be treated as erroneous. 48790075Sobrien 48890075SobrienA @dfn{preprocessing token} is a @dfn{preprocessing number} if it 48990075Sobrienbegins with a digit and is followed by letters, underscores, digits, 49090075Sobrienperiods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, 49190075Sobrien@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89 49290075Sobrienmode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot 49390075Sobrienappear in preprocessing numbers.) 49490075Sobrien 49590075SobrienTo make the above program fragment valid, place whitespace in front of 49690075Sobrienthe minus sign. This whitespace will end the preprocessing number. 49790075Sobrien@end itemize 49890075Sobrien 49990075Sobrien@node Fixed Headers 50090075Sobrien@section Fixed Header Files 50190075Sobrien 50290075SobrienGCC needs to install corrected versions of some system header files. 50390075SobrienThis is because most target systems have some header files that won't 50490075Sobrienwork with GCC unless they are changed. Some have bugs, some are 50590075Sobrienincompatible with ISO C, and some depend on special features of other 50690075Sobriencompilers. 50790075Sobrien 50890075SobrienInstalling GCC automatically creates and installs the fixed header 509169689Skanfiles, by running a program called @code{fixincludes}. Normally, you 51090075Sobriendon't need to pay attention to this. But there are cases where it 51190075Sobriendoesn't do the right thing automatically. 51290075Sobrien 51390075Sobrien@itemize @bullet 51490075Sobrien@item 51590075SobrienIf you update the system's header files, such as by installing a new 51690075Sobriensystem version, the fixed header files of GCC are not automatically 517169689Skanupdated. They can be updated using the @command{mkheaders} script 518169689Skaninstalled in 519169689Skan@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. 52090075Sobrien 52190075Sobrien@item 522169689SkanOn some systems, header file directories contain 52390075Sobrienmachine-specific symbolic links in certain places. This makes it 52490075Sobrienpossible to share most of the header files among hosts running the 525169689Skansame version of the system on different machine models. 52690075Sobrien 52790075SobrienThe programs that fix the header files do not understand this special 52890075Sobrienway of using symbolic links; therefore, the directory of fixed header 52990075Sobrienfiles is good only for the machine model used to build it. 53090075Sobrien 53190075SobrienIt is possible to make separate sets of fixed header files for the 53290075Sobriendifferent machine models, and arrange a structure of symbolic links so 53390075Sobrienas to use the proper set, but you'll have to do this by hand. 53490075Sobrien@end itemize 53590075Sobrien 53690075Sobrien@node Standard Libraries 53790075Sobrien@section Standard Libraries 53890075Sobrien 53990075Sobrien@opindex Wall 54090075SobrienGCC by itself attempts to be a conforming freestanding implementation. 54190075Sobrien@xref{Standards,,Language Standards Supported by GCC}, for details of 54290075Sobrienwhat this means. Beyond the library facilities required of such an 54390075Sobrienimplementation, the rest of the C library is supplied by the vendor of 54490075Sobrienthe operating system. If that C library doesn't conform to the C 54590075Sobrienstandards, then your programs might get warnings (especially when using 54690075Sobrien@option{-Wall}) that you don't expect. 54790075Sobrien 54890075SobrienFor example, the @code{sprintf} function on SunOS 4.1.3 returns 54990075Sobrien@code{char *} while the C standard says that @code{sprintf} returns an 55090075Sobrien@code{int}. The @code{fixincludes} program could make the prototype for 55190075Sobrienthis function match the Standard, but that would be wrong, since the 55290075Sobrienfunction will still return @code{char *}. 55390075Sobrien 55490075SobrienIf you need a Standard compliant library, then you need to find one, as 55590075SobrienGCC does not provide one. The GNU C library (called @code{glibc}) 55690075Sobrienprovides ISO C, POSIX, BSD, SystemV and X/Open compatibility for 55790075SobrienGNU/Linux and HURD-based GNU systems; no recent version of it supports 55890075Sobrienother systems, though some very old versions did. Version 2.2 of the 55990075SobrienGNU C library includes nearly complete C99 support. You could also ask 56090075Sobrienyour operating system vendor if newer libraries are available. 56190075Sobrien 56290075Sobrien@node Disappointments 56390075Sobrien@section Disappointments and Misunderstandings 56490075Sobrien 56590075SobrienThese problems are perhaps regrettable, but we don't know any practical 56690075Sobrienway around them. 56790075Sobrien 56890075Sobrien@itemize @bullet 56990075Sobrien@item 57090075SobrienCertain local variables aren't recognized by debuggers when you compile 57190075Sobrienwith optimization. 57290075Sobrien 57390075SobrienThis occurs because sometimes GCC optimizes the variable out of 57490075Sobrienexistence. There is no way to tell the debugger how to compute the 57590075Sobrienvalue such a variable ``would have had'', and it is not clear that would 57690075Sobrienbe desirable anyway. So GCC simply does not mention the eliminated 57790075Sobrienvariable when it writes debugging information. 57890075Sobrien 57990075SobrienYou have to expect a certain amount of disagreement between the 58090075Sobrienexecutable and your source code, when you use optimization. 58190075Sobrien 58290075Sobrien@cindex conflicting types 58390075Sobrien@cindex scope of declaration 58490075Sobrien@item 58590075SobrienUsers often think it is a bug when GCC reports an error for code 58690075Sobrienlike this: 58790075Sobrien 588132718Skan@smallexample 58990075Sobrienint foo (struct mumble *); 59090075Sobrien 59190075Sobrienstruct mumble @{ @dots{} @}; 59290075Sobrien 59390075Sobrienint foo (struct mumble *x) 59490075Sobrien@{ @dots{} @} 595132718Skan@end smallexample 59690075Sobrien 59790075SobrienThis code really is erroneous, because the scope of @code{struct 59890075Sobrienmumble} in the prototype is limited to the argument list containing it. 59990075SobrienIt does not refer to the @code{struct mumble} defined with file scope 60090075Sobrienimmediately below---they are two unrelated types with similar names in 60190075Sobriendifferent scopes. 60290075Sobrien 60390075SobrienBut in the definition of @code{foo}, the file-scope type is used 60490075Sobrienbecause that is available to be inherited. Thus, the definition and 60590075Sobrienthe prototype do not match, and you get an error. 60690075Sobrien 60790075SobrienThis behavior may seem silly, but it's what the ISO standard specifies. 60890075SobrienIt is easy enough for you to make your code work by moving the 60990075Sobriendefinition of @code{struct mumble} above the prototype. It's not worth 61090075Sobrienbeing incompatible with ISO C just to avoid an error for the example 61190075Sobrienshown above. 61290075Sobrien 61390075Sobrien@item 61490075SobrienAccesses to bit-fields even in volatile objects works by accessing larger 61590075Sobrienobjects, such as a byte or a word. You cannot rely on what size of 61690075Sobrienobject is accessed in order to read or write the bit-field; it may even 61790075Sobrienvary for a given bit-field according to the precise usage. 61890075Sobrien 61990075SobrienIf you care about controlling the amount of memory that is accessed, use 62090075Sobrienvolatile but do not use bit-fields. 62190075Sobrien 62290075Sobrien@item 62390075SobrienGCC comes with shell scripts to fix certain known problems in system 62490075Sobrienheader files. They install corrected copies of various header files in 62590075Sobriena special directory where only GCC will normally look for them. The 62690075Sobrienscripts adapt to various systems by searching all the system header 62790075Sobrienfiles for the problem cases that we know about. 62890075Sobrien 62990075SobrienIf new system header files are installed, nothing automatically arranges 630169689Skanto update the corrected header files. They can be updated using the 631169689Skan@command{mkheaders} script installed in 632169689Skan@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. 63390075Sobrien 63490075Sobrien@item 63590075Sobrien@cindex floating point precision 63690075SobrienOn 68000 and x86 systems, for instance, you can get paradoxical results 63790075Sobrienif you test the precise values of floating point numbers. For example, 63890075Sobrienyou can find that a floating point value which is not a NaN is not equal 63990075Sobriento itself. This results from the fact that the floating point registers 64090075Sobrienhold a few more bits of precision than fit in a @code{double} in memory. 64190075SobrienCompiled code moves values between memory and floating point registers 64290075Sobrienat its convenience, and moving them into memory truncates them. 64390075Sobrien 64490075Sobrien@opindex ffloat-store 64590075SobrienYou can partially avoid this problem by using the @option{-ffloat-store} 64690075Sobrienoption (@pxref{Optimize Options}). 64790075Sobrien 64890075Sobrien@item 64990075SobrienOn AIX and other platforms without weak symbol support, templates 65090075Sobrienneed to be instantiated explicitly and symbols for static members 65190075Sobrienof templates will not be generated. 652117395Skan 653117395Skan@item 654117395SkanOn AIX, GCC scans object files and library archives for static 655117395Skanconstructors and destructors when linking an application before the 656117395Skanlinker prunes unreferenced symbols. This is necessary to prevent the 657117395SkanAIX linker from mistakenly assuming that static constructor or 658117395Skandestructor are unused and removing them before the scanning can occur. 659117395SkanAll static constructors and destructors found will be referenced even 660117395Skanthough the modules in which they occur may not be used by the program. 661117395SkanThis may lead to both increased executable size and unexpected symbol 662117395Skanreferences. 66390075Sobrien@end itemize 66490075Sobrien 66590075Sobrien@node C++ Misunderstandings 66690075Sobrien@section Common Misunderstandings with GNU C++ 66790075Sobrien 66890075Sobrien@cindex misunderstandings in C++ 66990075Sobrien@cindex surprises in C++ 67090075Sobrien@cindex C++ misunderstandings 67190075SobrienC++ is a complex language and an evolving one, and its standard 67290075Sobriendefinition (the ISO C++ standard) was only recently completed. As a 67390075Sobrienresult, your C++ compiler may occasionally surprise you, even when its 67490075Sobrienbehavior is correct. This section discusses some areas that frequently 67590075Sobriengive rise to questions of this sort. 67690075Sobrien 67790075Sobrien@menu 67890075Sobrien* Static Definitions:: Static member declarations are not definitions 679132718Skan* Name lookup:: Name lookup, templates, and accessing members of base classes 68090075Sobrien* Temporaries:: Temporaries may vanish before you expect 68190075Sobrien* Copy Assignment:: Copy Assignment operators copy virtual bases twice 68290075Sobrien@end menu 68390075Sobrien 68490075Sobrien@node Static Definitions 68590075Sobrien@subsection Declare @emph{and} Define Static Members 68690075Sobrien 68790075Sobrien@cindex C++ static data, declaring and defining 68890075Sobrien@cindex static data in C++, declaring and defining 68990075Sobrien@cindex declaring static data in C++ 69090075Sobrien@cindex defining static data in C++ 69190075SobrienWhen a class has static data members, it is not enough to @emph{declare} 69290075Sobrienthe static member; you must also @emph{define} it. For example: 69390075Sobrien 694132718Skan@smallexample 69590075Sobrienclass Foo 69690075Sobrien@{ 69790075Sobrien @dots{} 69890075Sobrien void method(); 69990075Sobrien static int bar; 70090075Sobrien@}; 701132718Skan@end smallexample 70290075Sobrien 70390075SobrienThis declaration only establishes that the class @code{Foo} has an 70490075Sobrien@code{int} named @code{Foo::bar}, and a member function named 70590075Sobrien@code{Foo::method}. But you still need to define @emph{both} 70690075Sobrien@code{method} and @code{bar} elsewhere. According to the ISO 70790075Sobrienstandard, you must supply an initializer in one (and only one) source 70890075Sobrienfile, such as: 70990075Sobrien 710132718Skan@smallexample 71190075Sobrienint Foo::bar = 0; 712132718Skan@end smallexample 71390075Sobrien 71490075SobrienOther C++ compilers may not correctly implement the standard behavior. 715117395SkanAs a result, when you switch to @command{g++} from one of these compilers, 71690075Sobrienyou may discover that a program that appeared to work correctly in fact 717117395Skandoes not conform to the standard: @command{g++} reports as undefined 71890075Sobriensymbols any static data members that lack definitions. 71990075Sobrien 720132718Skan 721132718Skan@node Name lookup 722132718Skan@subsection Name lookup, templates, and accessing members of base classes 723132718Skan 724132718Skan@cindex base class members 725132718Skan@cindex two-stage name lookup 726132718Skan@cindex dependent name lookup 727132718Skan 728132718SkanThe C++ standard prescribes that all names that are not dependent on 729132718Skantemplate parameters are bound to their present definitions when parsing 730132718Skana template function or class.@footnote{The C++ standard just uses the 731132718Skanterm ``dependent'' for names that depend on the type or value of 732132718Skantemplate parameters. This shorter term will also be used in the rest of 733132718Skanthis section.} Only names that are dependent are looked up at the point 734132718Skanof instantiation. For example, consider 735132718Skan 736132718Skan@smallexample 737132718Skan void foo(double); 738132718Skan 739132718Skan struct A @{ 740132718Skan template <typename T> 741132718Skan void f () @{ 742169689Skan foo (1); // @r{1} 743169689Skan int i = N; // @r{2} 744132718Skan T t; 745169689Skan t.bar(); // @r{3} 746169689Skan foo (t); // @r{4} 747132718Skan @} 748132718Skan 749132718Skan static const int N; 750132718Skan @}; 751132718Skan@end smallexample 752132718Skan 753132718SkanHere, the names @code{foo} and @code{N} appear in a context that does 754132718Skannot depend on the type of @code{T}. The compiler will thus require that 755132718Skanthey are defined in the context of use in the template, not only before 756132718Skanthe point of instantiation, and will here use @code{::foo(double)} and 757132718Skan@code{A::N}, respectively. In particular, it will convert the integer 758132718Skanvalue to a @code{double} when passing it to @code{::foo(double)}. 759132718Skan 760132718SkanConversely, @code{bar} and the call to @code{foo} in the fourth marked 761132718Skanline are used in contexts that do depend on the type of @code{T}, so 762132718Skanthey are only looked up at the point of instantiation, and you can 763132718Skanprovide declarations for them after declaring the template, but before 764132718Skaninstantiating it. In particular, if you instantiate @code{A::f<int>}, 765132718Skanthe last line will call an overloaded @code{::foo(int)} if one was 766132718Skanprovided, even if after the declaration of @code{struct A}. 767132718Skan 768132718SkanThis distinction between lookup of dependent and non-dependent names is 769132718Skancalled two-stage (or dependent) name lookup. G++ implements it 770132718Skansince version 3.4. 771132718Skan 772132718SkanTwo-stage name lookup sometimes leads to situations with behavior 773169689Skandifferent from non-template codes. The most common is probably this: 774132718Skan 775132718Skan@smallexample 776132718Skan template <typename T> struct Base @{ 777132718Skan int i; 778132718Skan @}; 779132718Skan 780132718Skan template <typename T> struct Derived : public Base<T> @{ 781132718Skan int get_i() @{ return i; @} 782132718Skan @}; 783132718Skan@end smallexample 784132718Skan 785132718SkanIn @code{get_i()}, @code{i} is not used in a dependent context, so the 786132718Skancompiler will look for a name declared at the enclosing namespace scope 787132718Skan(which is the global scope here). It will not look into the base class, 788132718Skansince that is dependent and you may declare specializations of 789132718Skan@code{Base} even after declaring @code{Derived}, so the compiler can't 790132718Skanreally know what @code{i} would refer to. If there is no global 791132718Skanvariable @code{i}, then you will get an error message. 792132718Skan 793132718SkanIn order to make it clear that you want the member of the base class, 794132718Skanyou need to defer lookup until instantiation time, at which the base 795132718Skanclass is known. For this, you need to access @code{i} in a dependent 796132718Skancontext, by either using @code{this->i} (remember that @code{this} is of 797132718Skantype @code{Derived<T>*}, so is obviously dependent), or using 798169689Skan@code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought 799132718Skaninto scope by a @code{using}-declaration. 800132718Skan 801132718SkanAnother, similar example involves calling member functions of a base 802132718Skanclass: 803132718Skan 804132718Skan@smallexample 805132718Skan template <typename T> struct Base @{ 806132718Skan int f(); 807132718Skan @}; 808132718Skan 809132718Skan template <typename T> struct Derived : Base<T> @{ 810132718Skan int g() @{ return f(); @}; 811132718Skan @}; 812132718Skan@end smallexample 813132718Skan 814132718SkanAgain, the call to @code{f()} is not dependent on template arguments 815132718Skan(there are no arguments that depend on the type @code{T}, and it is also 816132718Skannot otherwise specified that the call should be in a dependent context). 817132718SkanThus a global declaration of such a function must be available, since 818132718Skanthe one in the base class is not visible until instantiation time. The 819132718Skancompiler will consequently produce the following error message: 820132718Skan 821132718Skan@smallexample 822132718Skan x.cc: In member function `int Derived<T>::g()': 823132718Skan x.cc:6: error: there are no arguments to `f' that depend on a template 824132718Skan parameter, so a declaration of `f' must be available 825132718Skan x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but 826132718Skan allowing the use of an undeclared name is deprecated) 827132718Skan@end smallexample 828132718Skan 829132718SkanTo make the code valid either use @code{this->f()}, or 830169689Skan@code{Base<T>::f()}. Using the @option{-fpermissive} flag will also let 831132718Skanthe compiler accept the code, by marking all function calls for which no 832132718Skandeclaration is visible at the time of definition of the template for 833132718Skanlater lookup at instantiation time, as if it were a dependent call. 834169689SkanWe do not recommend using @option{-fpermissive} to work around invalid 835132718Skancode, and it will also only catch cases where functions in base classes 836132718Skanare called, not where variables in base classes are used (as in the 837132718Skanexample above). 838132718Skan 839132718SkanNote that some compilers (including G++ versions prior to 3.4) get these 840132718Skanexamples wrong and accept above code without an error. Those compilers 841132718Skando not implement two-stage name lookup correctly. 842132718Skan 843132718Skan 84490075Sobrien@node Temporaries 84590075Sobrien@subsection Temporaries May Vanish Before You Expect 84690075Sobrien 84790075Sobrien@cindex temporaries, lifetime of 84890075Sobrien@cindex portions of temporary objects, pointers to 84990075SobrienIt is dangerous to use pointers or references to @emph{portions} of a 85090075Sobrientemporary object. The compiler may very well delete the object before 85190075Sobrienyou expect it to, leaving a pointer to garbage. The most common place 85290075Sobrienwhere this problem crops up is in classes like string classes, 85390075Sobrienespecially ones that define a conversion function to type @code{char *} 85490075Sobrienor @code{const char *}---which is one reason why the standard 85590075Sobrien@code{string} class requires you to call the @code{c_str} member 85690075Sobrienfunction. However, any class that returns a pointer to some internal 85790075Sobrienstructure is potentially subject to this problem. 85890075Sobrien 85990075SobrienFor example, a program may use a function @code{strfunc} that returns 86090075Sobrien@code{string} objects, and another function @code{charfunc} that 86190075Sobrienoperates on pointers to @code{char}: 86290075Sobrien 863132718Skan@smallexample 86490075Sobrienstring strfunc (); 86590075Sobrienvoid charfunc (const char *); 86690075Sobrien 86790075Sobrienvoid 86890075Sobrienf () 86990075Sobrien@{ 87090075Sobrien const char *p = strfunc().c_str(); 87190075Sobrien @dots{} 87290075Sobrien charfunc (p); 87390075Sobrien @dots{} 87490075Sobrien charfunc (p); 87590075Sobrien@} 876132718Skan@end smallexample 87790075Sobrien 87890075Sobrien@noindent 87990075SobrienIn this situation, it may seem reasonable to save a pointer to the C 88090075Sobrienstring returned by the @code{c_str} member function and use that rather 88190075Sobrienthan call @code{c_str} repeatedly. However, the temporary string 88290075Sobriencreated by the call to @code{strfunc} is destroyed after @code{p} is 88390075Sobrieninitialized, at which point @code{p} is left pointing to freed memory. 88490075Sobrien 88590075SobrienCode like this may run successfully under some other compilers, 88690075Sobrienparticularly obsolete cfront-based compilers that delete temporaries 88790075Sobrienalong with normal local variables. However, the GNU C++ behavior is 88890075Sobrienstandard-conforming, so if your program depends on late destruction of 88990075Sobrientemporaries it is not portable. 89090075Sobrien 89190075SobrienThe safe way to write such code is to give the temporary a name, which 89290075Sobrienforces it to remain until the end of the scope of the name. For 89390075Sobrienexample: 89490075Sobrien 895132718Skan@smallexample 896146895Skanconst string& tmp = strfunc (); 89790075Sobriencharfunc (tmp.c_str ()); 898132718Skan@end smallexample 89990075Sobrien 90090075Sobrien@node Copy Assignment 90190075Sobrien@subsection Implicit Copy-Assignment for Virtual Bases 90290075Sobrien 90390075SobrienWhen a base class is virtual, only one subobject of the base class 90490075Sobrienbelongs to each full object. Also, the constructors and destructors are 90590075Sobrieninvoked only once, and called from the most-derived class. However, such 90690075Sobrienobjects behave unspecified when being assigned. For example: 90790075Sobrien 908132718Skan@smallexample 90990075Sobrienstruct Base@{ 91090075Sobrien char *name; 91190075Sobrien Base(char *n) : name(strdup(n))@{@} 91290075Sobrien Base& operator= (const Base& other)@{ 91390075Sobrien free (name); 91490075Sobrien name = strdup (other.name); 91590075Sobrien @} 91690075Sobrien@}; 91790075Sobrien 91890075Sobrienstruct A:virtual Base@{ 91990075Sobrien int val; 92090075Sobrien A():Base("A")@{@} 92190075Sobrien@}; 92290075Sobrien 92390075Sobrienstruct B:virtual Base@{ 92490075Sobrien int bval; 92590075Sobrien B():Base("B")@{@} 92690075Sobrien@}; 92790075Sobrien 92890075Sobrienstruct Derived:public A, public B@{ 92990075Sobrien Derived():Base("Derived")@{@} 93090075Sobrien@}; 93190075Sobrien 93290075Sobrienvoid func(Derived &d1, Derived &d2) 93390075Sobrien@{ 93490075Sobrien d1 = d2; 93590075Sobrien@} 936132718Skan@end smallexample 93790075Sobrien 93890075SobrienThe C++ standard specifies that @samp{Base::Base} is only called once 93990075Sobrienwhen constructing or copy-constructing a Derived object. It is 94090075Sobrienunspecified whether @samp{Base::operator=} is called more than once when 94190075Sobrienthe implicit copy-assignment for Derived objects is invoked (as it is 94290075Sobrieninside @samp{func} in the example). 94390075Sobrien 944132718SkanG++ implements the ``intuitive'' algorithm for copy-assignment: assign all 94590075Sobriendirect bases, then assign all members. In that algorithm, the virtual 946119256Skanbase subobject can be encountered more than once. In the example, copying 94790075Sobrienproceeds in the following order: @samp{val}, @samp{name} (via 94890075Sobrien@code{strdup}), @samp{bval}, and @samp{name} again. 94990075Sobrien 95090075SobrienIf application code relies on copy-assignment, a user-defined 95190075Sobriencopy-assignment operator removes any uncertainties. With such an 95290075Sobrienoperator, the application can define whether and how the virtual base 95390075Sobriensubobject is assigned. 95490075Sobrien 95590075Sobrien@node Protoize Caveats 95690075Sobrien@section Caveats of using @command{protoize} 95790075Sobrien 95890075SobrienThe conversion programs @command{protoize} and @command{unprotoize} can 95990075Sobriensometimes change a source file in a way that won't work unless you 96090075Sobrienrearrange it. 96190075Sobrien 96290075Sobrien@itemize @bullet 96390075Sobrien@item 96490075Sobrien@command{protoize} can insert references to a type name or type tag before 96590075Sobrienthe definition, or in a file where they are not defined. 96690075Sobrien 96790075SobrienIf this happens, compiler error messages should show you where the new 96890075Sobrienreferences are, so fixing the file by hand is straightforward. 96990075Sobrien 97090075Sobrien@item 97190075SobrienThere are some C constructs which @command{protoize} cannot figure out. 97290075SobrienFor example, it can't determine argument types for declaring a 97390075Sobrienpointer-to-function variable; this you must do by hand. @command{protoize} 97490075Sobrieninserts a comment containing @samp{???} each time it finds such a 97590075Sobrienvariable; so you can find all such variables by searching for this 97690075Sobrienstring. ISO C does not require declaring the argument types of 97790075Sobrienpointer-to-function types. 97890075Sobrien 97990075Sobrien@item 98090075SobrienUsing @command{unprotoize} can easily introduce bugs. If the program 98190075Sobrienrelied on prototypes to bring about conversion of arguments, these 98290075Sobrienconversions will not take place in the program without prototypes. 98390075SobrienOne case in which you can be sure @command{unprotoize} is safe is when 98490075Sobrienyou are removing prototypes that were made with @command{protoize}; if 98590075Sobrienthe program worked before without any prototypes, it will work again 98690075Sobrienwithout them. 98790075Sobrien 98890075Sobrien@opindex Wconversion 98990075SobrienYou can find all the places where this problem might occur by compiling 99090075Sobrienthe program with the @option{-Wconversion} option. It prints a warning 99190075Sobrienwhenever an argument is converted. 99290075Sobrien 99390075Sobrien@item 99490075SobrienBoth conversion programs can be confused if there are macro calls in and 99590075Sobrienaround the text to be converted. In other words, the standard syntax 99690075Sobrienfor a declaration or definition must not result from expanding a macro. 99790075SobrienThis problem is inherent in the design of C and cannot be fixed. If 99890075Sobrienonly a few functions have confusing macro calls, you can easily convert 99990075Sobrienthem manually. 100090075Sobrien 100190075Sobrien@item 100290075Sobrien@command{protoize} cannot get the argument types for a function whose 100390075Sobriendefinition was not actually compiled due to preprocessing conditionals. 100490075SobrienWhen this happens, @command{protoize} changes nothing in regard to such 100590075Sobriena function. @command{protoize} tries to detect such instances and warn 100690075Sobrienabout them. 100790075Sobrien 100890075SobrienYou can generally work around this problem by using @command{protoize} step 100990075Sobrienby step, each time specifying a different set of @option{-D} options for 101090075Sobriencompilation, until all of the functions have been converted. There is 101190075Sobrienno automatic way to verify that you have got them all, however. 101290075Sobrien 101390075Sobrien@item 101490075SobrienConfusion may result if there is an occasion to convert a function 101590075Sobriendeclaration or definition in a region of source code where there is more 101690075Sobrienthan one formal parameter list present. Thus, attempts to convert code 101790075Sobriencontaining multiple (conditionally compiled) versions of a single 101890075Sobrienfunction header (in the same vicinity) may not produce the desired (or 101990075Sobrienexpected) results. 102090075Sobrien 102190075SobrienIf you plan on converting source files which contain such code, it is 102290075Sobrienrecommended that you first make sure that each conditionally compiled 102390075Sobrienregion of source code which contains an alternative function header also 102490075Sobriencontains at least one additional follower token (past the final right 102590075Sobrienparenthesis of the function header). This should circumvent the 102690075Sobrienproblem. 102790075Sobrien 102890075Sobrien@item 102990075Sobrien@command{unprotoize} can become confused when trying to convert a function 103090075Sobriendefinition or declaration which contains a declaration for a 103190075Sobrienpointer-to-function formal argument which has the same name as the 103290075Sobrienfunction being defined or declared. We recommend you avoid such choices 103390075Sobrienof formal parameter names. 103490075Sobrien 103590075Sobrien@item 103690075SobrienYou might also want to correct some of the indentation by hand and break 103790075Sobrienlong lines. (The conversion programs don't write lines longer than 103890075Sobrieneighty characters in any case.) 103990075Sobrien@end itemize 104090075Sobrien 104190075Sobrien@node Non-bugs 104290075Sobrien@section Certain Changes We Don't Want to Make 104390075Sobrien 104490075SobrienThis section lists changes that people frequently request, but which 104590075Sobrienwe do not make because we think GCC is better without them. 104690075Sobrien 104790075Sobrien@itemize @bullet 104890075Sobrien@item 104990075SobrienChecking the number and type of arguments to a function which has an 105090075Sobrienold-fashioned definition and no prototype. 105190075Sobrien 105290075SobrienSuch a feature would work only occasionally---only for calls that appear 105390075Sobrienin the same file as the called function, following the definition. The 105490075Sobrienonly way to check all calls reliably is to add a prototype for the 105590075Sobrienfunction. But adding a prototype eliminates the motivation for this 105690075Sobrienfeature. So the feature is not worthwhile. 105790075Sobrien 105890075Sobrien@item 105990075SobrienWarning about using an expression whose type is signed as a shift count. 106090075Sobrien 106190075SobrienShift count operands are probably signed more often than unsigned. 106290075SobrienWarning about this would cause far more annoyance than good. 106390075Sobrien 106490075Sobrien@item 106590075SobrienWarning about assigning a signed value to an unsigned variable. 106690075Sobrien 106790075SobrienSuch assignments must be very common; warning about them would cause 106890075Sobrienmore annoyance than good. 106990075Sobrien 107090075Sobrien@item 107190075SobrienWarning when a non-void function value is ignored. 107290075Sobrien 1073132718SkanC contains many standard functions that return a value that most 1074132718Skanprograms choose to ignore. One obvious example is @code{printf}. 1075132718SkanWarning about this practice only leads the defensive programmer to 1076132718Skanclutter programs with dozens of casts to @code{void}. Such casts are 1077132718Skanrequired so frequently that they become visual noise. Writing those 1078132718Skancasts becomes so automatic that they no longer convey useful 1079132718Skaninformation about the intentions of the programmer. For functions 1080132718Skanwhere the return value should never be ignored, use the 1081132718Skan@code{warn_unused_result} function attribute (@pxref{Function 1082132718SkanAttributes}). 108390075Sobrien 108490075Sobrien@item 108590075Sobrien@opindex fshort-enums 108690075SobrienMaking @option{-fshort-enums} the default. 108790075Sobrien 108890075SobrienThis would cause storage layout to be incompatible with most other C 108990075Sobriencompilers. And it doesn't seem very important, given that you can get 109090075Sobrienthe same result in other ways. The case where it matters most is when 109190075Sobrienthe enumeration-valued object is inside a structure, and in that case 109290075Sobrienyou can specify a field width explicitly. 109390075Sobrien 109490075Sobrien@item 109590075SobrienMaking bit-fields unsigned by default on particular machines where ``the 109690075SobrienABI standard'' says to do so. 109790075Sobrien 109890075SobrienThe ISO C standard leaves it up to the implementation whether a bit-field 109990075Sobriendeclared plain @code{int} is signed or not. This in effect creates two 110090075Sobrienalternative dialects of C@. 110190075Sobrien 110290075Sobrien@opindex fsigned-bitfields 110390075Sobrien@opindex funsigned-bitfields 110490075SobrienThe GNU C compiler supports both dialects; you can specify the signed 110590075Sobriendialect with @option{-fsigned-bitfields} and the unsigned dialect with 110690075Sobrien@option{-funsigned-bitfields}. However, this leaves open the question of 110790075Sobrienwhich dialect to use by default. 110890075Sobrien 110990075SobrienCurrently, the preferred dialect makes plain bit-fields signed, because 111090075Sobrienthis is simplest. Since @code{int} is the same as @code{signed int} in 111190075Sobrienevery other context, it is cleanest for them to be the same in bit-fields 111290075Sobrienas well. 111390075Sobrien 111490075SobrienSome computer manufacturers have published Application Binary Interface 111590075Sobrienstandards which specify that plain bit-fields should be unsigned. It is 111690075Sobriena mistake, however, to say anything about this issue in an ABI@. This is 111790075Sobrienbecause the handling of plain bit-fields distinguishes two dialects of C@. 111890075SobrienBoth dialects are meaningful on every type of machine. Whether a 111990075Sobrienparticular object file was compiled using signed bit-fields or unsigned 112090075Sobrienis of no concern to other object files, even if they access the same 112190075Sobrienbit-fields in the same data structures. 112290075Sobrien 112390075SobrienA given program is written in one or the other of these two dialects. 112490075SobrienThe program stands a chance to work on most any machine if it is 112590075Sobriencompiled with the proper dialect. It is unlikely to work at all if 112690075Sobriencompiled with the wrong dialect. 112790075Sobrien 112890075SobrienMany users appreciate the GNU C compiler because it provides an 112990075Sobrienenvironment that is uniform across machines. These users would be 113090075Sobrieninconvenienced if the compiler treated plain bit-fields differently on 113190075Sobriencertain machines. 113290075Sobrien 113390075SobrienOccasionally users write programs intended only for a particular machine 113490075Sobrientype. On these occasions, the users would benefit if the GNU C compiler 113590075Sobrienwere to support by default the same dialect as the other compilers on 113690075Sobrienthat machine. But such applications are rare. And users writing a 113790075Sobrienprogram to run on more than one type of machine cannot possibly benefit 113890075Sobrienfrom this kind of compatibility. 113990075Sobrien 114090075SobrienThis is why GCC does and will treat plain bit-fields in the same 114190075Sobrienfashion on all types of machines (by default). 114290075Sobrien 114390075SobrienThere are some arguments for making bit-fields unsigned by default on all 114490075Sobrienmachines. If, for example, this becomes a universal de facto standard, 114590075Sobrienit would make sense for GCC to go along with it. This is something 114690075Sobriento be considered in the future. 114790075Sobrien 114890075Sobrien(Of course, users strongly concerned about portability should indicate 114990075Sobrienexplicitly in each bit-field whether it is signed or not. In this way, 115090075Sobrienthey write programs which have the same meaning in both C dialects.) 115190075Sobrien 115290075Sobrien@item 115390075Sobrien@opindex ansi 115490075Sobrien@opindex std 115590075SobrienUndefining @code{__STDC__} when @option{-ansi} is not used. 115690075Sobrien 1157117395SkanCurrently, GCC defines @code{__STDC__} unconditionally. This provides 1158117395Skangood results in practice. 115990075Sobrien 116090075SobrienProgrammers normally use conditionals on @code{__STDC__} to ask whether 116190075Sobrienit is safe to use certain features of ISO C, such as function 116290075Sobrienprototypes or ISO token concatenation. Since plain @command{gcc} supports 116390075Sobrienall the features of ISO C, the correct answer to these questions is 116490075Sobrien``yes''. 116590075Sobrien 116690075SobrienSome users try to use @code{__STDC__} to check for the availability of 116790075Sobriencertain library facilities. This is actually incorrect usage in an ISO 116890075SobrienC program, because the ISO C standard says that a conforming 116990075Sobrienfreestanding implementation should define @code{__STDC__} even though it 117090075Sobriendoes not have the library facilities. @samp{gcc -ansi -pedantic} is a 117190075Sobrienconforming freestanding implementation, and it is therefore required to 117290075Sobriendefine @code{__STDC__}, even though it does not come with an ISO C 117390075Sobrienlibrary. 117490075Sobrien 117590075SobrienSometimes people say that defining @code{__STDC__} in a compiler that 117690075Sobriendoes not completely conform to the ISO C standard somehow violates the 117790075Sobrienstandard. This is illogical. The standard is a standard for compilers 117890075Sobrienthat claim to support ISO C, such as @samp{gcc -ansi}---not for other 117990075Sobriencompilers such as plain @command{gcc}. Whatever the ISO C standard says 118090075Sobrienis relevant to the design of plain @command{gcc} without @option{-ansi} only 118190075Sobrienfor pragmatic reasons, not as a requirement. 118290075Sobrien 118390075SobrienGCC normally defines @code{__STDC__} to be 1, and in addition 118490075Sobriendefines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, 118590075Sobrienor a @option{-std} option for strict conformance to some version of ISO C@. 118690075SobrienOn some hosts, system include files use a different convention, where 118790075Sobrien@code{__STDC__} is normally 0, but is 1 if the user specifies strict 118890075Sobrienconformance to the C Standard. GCC follows the host convention when 118990075Sobrienprocessing system include files, but when processing user files it follows 119090075Sobrienthe usual GNU C convention. 119190075Sobrien 119290075Sobrien@item 119390075SobrienUndefining @code{__STDC__} in C++. 119490075Sobrien 119590075SobrienPrograms written to compile with C++-to-C translators get the 119690075Sobrienvalue of @code{__STDC__} that goes with the C compiler that is 119790075Sobriensubsequently used. These programs must test @code{__STDC__} 119890075Sobriento determine what kind of C preprocessor that compiler uses: 119990075Sobrienwhether they should concatenate tokens in the ISO C fashion 120090075Sobrienor in the traditional fashion. 120190075Sobrien 120290075SobrienThese programs work properly with GNU C++ if @code{__STDC__} is defined. 120390075SobrienThey would not work otherwise. 120490075Sobrien 120590075SobrienIn addition, many header files are written to provide prototypes in ISO 120690075SobrienC but not in traditional C@. Many of these header files can work without 120790075Sobrienchange in C++ provided @code{__STDC__} is defined. If @code{__STDC__} 120890075Sobrienis not defined, they will all fail, and will all need to be changed to 120990075Sobrientest explicitly for C++ as well. 121090075Sobrien 121190075Sobrien@item 121290075SobrienDeleting ``empty'' loops. 121390075Sobrien 121490075SobrienHistorically, GCC has not deleted ``empty'' loops under the 121590075Sobrienassumption that the most likely reason you would put one in a program is 121690075Sobriento have a delay, so deleting them will not make real programs run any 121790075Sobrienfaster. 121890075Sobrien 121990075SobrienHowever, the rationale here is that optimization of a nonempty loop 1220169689Skancannot produce an empty one. This held for carefully written C compiled 1221169689Skanwith less powerful optimizers but is not always the case for carefully 1222169689Skanwritten C++ or with more powerful optimizers. 1223169689SkanThus GCC will remove operations from loops whenever it can determine 1224169689Skanthose operations are not externally visible (apart from the time taken 1225169689Skanto execute them, of course). In case the loop can be proved to be finite, 1226169689SkanGCC will also remove the loop itself. 122790075Sobrien 1228169689SkanBe aware of this when performing timing tests, for instance the 1229169689Skanfollowing loop can be completely removed, provided 1230169689Skan@code{some_expression} can provably not change any global state. 123190075Sobrien 1232169689Skan@smallexample 1233169689Skan@{ 1234169689Skan int sum = 0; 1235169689Skan int ix; 1236169689Skan 1237169689Skan for (ix = 0; ix != 10000; ix++) 1238169689Skan sum += some_expression; 1239169689Skan@} 1240169689Skan@end smallexample 1241169689Skan 1242169689SkanEven though @code{sum} is accumulated in the loop, no use is made of 1243169689Skanthat summation, so the accumulation can be removed. 1244169689Skan 124590075Sobrien@item 124690075SobrienMaking side effects happen in the same order as in some other compiler. 124790075Sobrien 124890075Sobrien@cindex side effects, order of evaluation 124990075Sobrien@cindex order of evaluation, side effects 125090075SobrienIt is never safe to depend on the order of evaluation of side effects. 125190075SobrienFor example, a function call like this may very well behave differently 125290075Sobrienfrom one compiler to another: 125390075Sobrien 1254132718Skan@smallexample 125590075Sobrienvoid func (int, int); 125690075Sobrien 125790075Sobrienint i = 2; 125890075Sobrienfunc (i++, i++); 1259132718Skan@end smallexample 126090075Sobrien 126190075SobrienThere is no guarantee (in either the C or the C++ standard language 126290075Sobriendefinitions) that the increments will be evaluated in any particular 126390075Sobrienorder. Either increment might happen first. @code{func} might get the 126490075Sobrienarguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. 126590075Sobrien 126690075Sobrien@item 126790075SobrienMaking certain warnings into errors by default. 126890075Sobrien 126990075SobrienSome ISO C testsuites report failure when the compiler does not produce 127090075Sobrienan error message for a certain program. 127190075Sobrien 127290075Sobrien@opindex pedantic-errors 127390075SobrienISO C requires a ``diagnostic'' message for certain kinds of invalid 127490075Sobrienprograms, but a warning is defined by GCC to count as a diagnostic. If 127590075SobrienGCC produces a warning but not an error, that is correct ISO C support. 1276132718SkanIf testsuites call this ``failure'', they should be run with the GCC 127790075Sobrienoption @option{-pedantic-errors}, which will turn these warnings into 127890075Sobrienerrors. 127990075Sobrien 128090075Sobrien@end itemize 128190075Sobrien 128290075Sobrien@node Warnings and Errors 128390075Sobrien@section Warning Messages and Error Messages 128490075Sobrien 128590075Sobrien@cindex error messages 128690075Sobrien@cindex warnings vs errors 128790075Sobrien@cindex messages, warning and error 128890075SobrienThe GNU compiler can produce two kinds of diagnostics: errors and 128990075Sobrienwarnings. Each kind has a different purpose: 129090075Sobrien 129190075Sobrien@itemize @w{} 129290075Sobrien@item 129390075Sobrien@dfn{Errors} report problems that make it impossible to compile your 129490075Sobrienprogram. GCC reports errors with the source file name and line 129590075Sobriennumber where the problem is apparent. 129690075Sobrien 129790075Sobrien@item 129890075Sobrien@dfn{Warnings} report other unusual conditions in your code that 129990075Sobrien@emph{may} indicate a problem, although compilation can (and does) 130090075Sobrienproceed. Warning messages also report the source file name and line 130190075Sobriennumber, but include the text @samp{warning:} to distinguish them 130290075Sobrienfrom error messages. 130390075Sobrien@end itemize 130490075Sobrien 130590075SobrienWarnings may indicate danger points where you should check to make sure 130690075Sobrienthat your program really does what you intend; or the use of obsolete 130790075Sobrienfeatures; or the use of nonstandard features of GNU C or C++. Many 130890075Sobrienwarnings are issued only if you ask for them, with one of the @option{-W} 130990075Sobrienoptions (for instance, @option{-Wall} requests a variety of useful 131090075Sobrienwarnings). 131190075Sobrien 131290075Sobrien@opindex pedantic 131390075Sobrien@opindex pedantic-errors 131490075SobrienGCC always tries to compile your program if possible; it never 131590075Sobriengratuitously rejects a program whose meaning is clear merely because 131690075Sobrien(for instance) it fails to conform to a standard. In some cases, 131790075Sobrienhowever, the C and C++ standards specify that certain extensions are 131890075Sobrienforbidden, and a diagnostic @emph{must} be issued by a conforming 131990075Sobriencompiler. The @option{-pedantic} option tells GCC to issue warnings in 132090075Sobriensuch cases; @option{-pedantic-errors} says to make them errors instead. 132190075SobrienThis does not mean that @emph{all} non-ISO constructs get warnings 132290075Sobrienor errors. 132390075Sobrien 132490075Sobrien@xref{Warning Options,,Options to Request or Suppress Warnings}, for 132590075Sobrienmore detail on these and related command-line options. 1326