Mercurial > hg > CbC > CbC_gcc

comparison gcc/doc/trouble.texi @ 55:77e2b8dfacca gcc-4.4.5

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update it from 4.4.3 to 4.5.0
author ryoma <e075725@ie.u-ryukyu.ac.jp>
date Fri, 12 Feb 2010 23:39:51 +0900
parents a06113de4d67
children b7f97abdc517
comparison
equal deleted inserted replaced
52:c156f1bd5cd9 55:77e2b8dfacca
1 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
2 @c 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008 2 @c 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008, 2009
3 @c Free Software Foundation, Inc. 3 @c Free Software Foundation, Inc.
4 @c This is part of the GCC manual. 4 @c This is part of the GCC manual.
5 @c For copying conditions, see the file gcc.texi. 5 @c For copying conditions, see the file gcc.texi.
6 6
7 @node Trouble 7 @node Trouble
28 This is necessary, but doesn't always work smoothly. 28 This is necessary, but doesn't always work smoothly.
29 * Standard Libraries:: GCC uses the system C library, which might not be 29 * Standard Libraries:: GCC uses the system C library, which might not be
30 compliant with the ISO C standard. 30 compliant with the ISO C standard.
31 * Disappointments:: Regrettable things we can't change, but not quite bugs. 31 * Disappointments:: Regrettable things we can't change, but not quite bugs.
32 * C++ Misunderstandings:: Common misunderstandings with GNU C++. 32 * C++ Misunderstandings:: Common misunderstandings with GNU C++.
33 * Protoize Caveats:: Things to watch out for when using @code{protoize}.
34 * Non-bugs:: Things we think are right, but some others disagree. 33 * Non-bugs:: Things we think are right, but some others disagree.
35 * Warnings and Errors:: Which problems in your code get warnings, 34 * Warnings and Errors:: Which problems in your code get warnings,
36 and which get errors. 35 and which get errors.
37 @end menu 36 @end menu
38 37
43 @item 42 @item
44 The @code{fixincludes} script interacts badly with automounters; if the 43 The @code{fixincludes} script interacts badly with automounters; if the
45 directory of system header files is automounted, it tends to be 44 directory of system header files is automounted, it tends to be
46 unmounted while @code{fixincludes} is running. This would seem to be a 45 unmounted while @code{fixincludes} is running. This would seem to be a
47 bug in the automounter. We don't know any good way to work around it. 46 bug in the automounter. We don't know any good way to work around it.
48
49 @item
50 The @code{fixproto} script will sometimes add prototypes for the
51 @code{sigsetjmp} and @code{siglongjmp} functions that reference the
52 @code{jmp_buf} type before that type is defined. To work around this,
53 edit the offending file and place the typedef in front of the
54 prototypes.
55 @end itemize 47 @end itemize
56 48
57 @node Cross-Compiler Problems 49 @node Cross-Compiler Problems
58 @section Cross-Compiler Problems 50 @section Cross-Compiler Problems
59 51
348 @item 340 @item
349 Declarations of external variables and functions within a block apply 341 Declarations of external variables and functions within a block apply
350 only to the block containing the declaration. In other words, they 342 only to the block containing the declaration. In other words, they
351 have the same scope as any other declaration in the same place. 343 have the same scope as any other declaration in the same place.
352 344
353 In some other C compilers, a @code{extern} declaration affects all the 345 In some other C compilers, an @code{extern} declaration affects all the
354 rest of the file even if it happens within a block. 346 rest of the file even if it happens within a block.
355 347
356 @item 348 @item
357 In traditional C, you can combine @code{long}, etc., with a typedef name, 349 In traditional C, you can combine @code{long}, etc., with a typedef name,
358 as shown here: 350 as shown here:
937 If application code relies on copy-assignment, a user-defined 929 If application code relies on copy-assignment, a user-defined
938 copy-assignment operator removes any uncertainties. With such an 930 copy-assignment operator removes any uncertainties. With such an
939 operator, the application can define whether and how the virtual base 931 operator, the application can define whether and how the virtual base
940 subobject is assigned. 932 subobject is assigned.
941 933
942 @node Protoize Caveats
943 @section Caveats of using @command{protoize}
944
945 The conversion programs @command{protoize} and @command{unprotoize} can
946 sometimes change a source file in a way that won't work unless you
947 rearrange it.
948
949 @itemize @bullet
950 @item
951 @command{protoize} can insert references to a type name or type tag before
952 the definition, or in a file where they are not defined.
953
954 If this happens, compiler error messages should show you where the new
955 references are, so fixing the file by hand is straightforward.
956
957 @item
958 There are some C constructs which @command{protoize} cannot figure out.
959 For example, it can't determine argument types for declaring a
960 pointer-to-function variable; this you must do by hand. @command{protoize}
961 inserts a comment containing @samp{???} each time it finds such a
962 variable; so you can find all such variables by searching for this
963 string. ISO C does not require declaring the argument types of
964 pointer-to-function types.
965
966 @item
967 Using @command{unprotoize} can easily introduce bugs. If the program
968 relied on prototypes to bring about conversion of arguments, these
969 conversions will not take place in the program without prototypes.
970 One case in which you can be sure @command{unprotoize} is safe is when
971 you are removing prototypes that were made with @command{protoize}; if
972 the program worked before without any prototypes, it will work again
973 without them.
974
975 @opindex Wtraditional-conversion
976 You can find all the places where this problem might occur by compiling
977 the program with the @option{-Wtraditional-conversion} option. It
978 prints a warning whenever an argument is converted.
979
980 @item
981 Both conversion programs can be confused if there are macro calls in and
982 around the text to be converted. In other words, the standard syntax
983 for a declaration or definition must not result from expanding a macro.
984 This problem is inherent in the design of C and cannot be fixed. If
985 only a few functions have confusing macro calls, you can easily convert
986 them manually.
987
988 @item
989 @command{protoize} cannot get the argument types for a function whose
990 definition was not actually compiled due to preprocessing conditionals.
991 When this happens, @command{protoize} changes nothing in regard to such
992 a function. @command{protoize} tries to detect such instances and warn
993 about them.
994
995 You can generally work around this problem by using @command{protoize} step
996 by step, each time specifying a different set of @option{-D} options for
997 compilation, until all of the functions have been converted. There is
998 no automatic way to verify that you have got them all, however.
999
1000 @item
1001 Confusion may result if there is an occasion to convert a function
1002 declaration or definition in a region of source code where there is more
1003 than one formal parameter list present. Thus, attempts to convert code
1004 containing multiple (conditionally compiled) versions of a single
1005 function header (in the same vicinity) may not produce the desired (or
1006 expected) results.
1007
1008 If you plan on converting source files which contain such code, it is
1009 recommended that you first make sure that each conditionally compiled
1010 region of source code which contains an alternative function header also
1011 contains at least one additional follower token (past the final right
1012 parenthesis of the function header). This should circumvent the
1013 problem.
1014
1015 @item
1016 @command{unprotoize} can become confused when trying to convert a function
1017 definition or declaration which contains a declaration for a
1018 pointer-to-function formal argument which has the same name as the
1019 function being defined or declared. We recommend you avoid such choices
1020 of formal parameter names.
1021
1022 @item
1023 You might also want to correct some of the indentation by hand and break
1024 long lines. (The conversion programs don't write lines longer than
1025 eighty characters in any case.)
1026 @end itemize
1027
1028 @node Non-bugs 934 @node Non-bugs
1029 @section Certain Changes We Don't Want to Make 935 @section Certain Changes We Don't Want to Make
1030 936
1031 This section lists changes that people frequently request, but which 937 This section lists changes that people frequently request, but which
1032 we do not make because we think GCC is better without them. 938 we do not make because we think GCC is better without them.