2007-05-22 H.J. Lu <hongjiu.lu@intel.com>
[official-gcc.git] / gcc / README.Portability
blob32a33e27bec854a4d6b9468008751ba47a632bb1
1 Copyright (C) 2000, 2003 Free Software Foundation, Inc.
3 This file is intended to contain a few notes about writing C code
4 within GCC so that it compiles without error on the full range of
5 compilers GCC needs to be able to compile on.
7 The problem is that many ISO-standard constructs are not accepted by
8 either old or buggy compilers, and we keep getting bitten by them.
9 This knowledge until know has been sparsely spread around, so I
10 thought I'd collect it in one useful place.  Please add and correct
11 any problems as you come across them.
13 I'm going to start from a base of the ISO C90 standard, since that is
14 probably what most people code to naturally.  Obviously using
15 constructs introduced after that is not a good idea.
17 For the complete coding style conventions used in GCC, please read
18 http://gcc.gnu.org/codingconventions.html
21 String literals
22 ---------------
24 Irix6 "cc -n32" and OSF4 "cc" have problems with constant string
25 initializers with parens around it, e.g.
27 const char string[] = ("A string");
29 This is unfortunate since this is what the GNU gettext macro N_
30 produces.  You need to find a different way to code it.
32 Some compilers like MSVC++ have fairly low limits on the maximum
33 length of a string literal; 509 is the lowest we've come across.  You
34 may need to break up a long printf statement into many smaller ones.
37 Empty macro arguments
38 ---------------------
40 ISO C (6.8.3 in the 1990 standard) specifies the following:
42 If (before argument substitution) any argument consists of no
43 preprocessing tokens, the behavior is undefined.
45 This was relaxed by ISO C99, but some older compilers emit an error,
46 so code like
48 #define foo(x, y) x y
49 foo (bar, )
51 needs to be coded in some other way.
54 free and realloc
55 ----------------
57 Some implementations crash upon attempts to free or realloc the null
58 pointer.  Thus if mem might be null, you need to write
60   if (mem)
61     free (mem);
64 Trigraphs
65 ---------
67 You weren't going to use them anyway, but some otherwise ISO C
68 compliant compilers do not accept trigraphs.
71 Suffixes on Integer Constants
72 -----------------------------
74 You should never use a 'l' suffix on integer constants ('L' is fine),
75 since it can easily be confused with the number '1'.
78                         Common Coding Pitfalls
79                         ======================
81 errno
82 -----
84 errno might be declared as a macro.
87 Implicit int
88 ------------
90 In C, the 'int' keyword can often be omitted from type declarations.
91 For instance, you can write
93   unsigned variable;
95 as shorthand for
97   unsigned int variable;
99 There are several places where this can cause trouble.  First, suppose
100 'variable' is a long; then you might think
102   (unsigned) variable
104 would convert it to unsigned long.  It does not.  It converts to
105 unsigned int.  This mostly causes problems on 64-bit platforms, where
106 long and int are not the same size.
108 Second, if you write a function definition with no return type at
109 all:
111   operate (int a, int b)
112   {
113     ...
114   }
116 that function is expected to return int, *not* void.  GCC will warn
117 about this.
119 Implicit function declarations always have return type int.  So if you
120 correct the above definition to
122   void
123   operate (int a, int b)
124   ...
126 but operate() is called above its definition, you will get an error
127 about a "type mismatch with previous implicit declaration".  The cure
128 is to prototype all functions at the top of the file, or in an
129 appropriate header.
131 Char vs unsigned char vs int
132 ----------------------------
134 In C, unqualified 'char' may be either signed or unsigned; it is the
135 implementation's choice.  When you are processing 7-bit ASCII, it does
136 not matter.  But when your program must handle arbitrary binary data,
137 or fully 8-bit character sets, you have a problem.  The most obvious
138 issue is if you have a look-up table indexed by characters.
140 For instance, the character '\341' in ISO Latin 1 is SMALL LETTER A
141 WITH ACUTE ACCENT.  In the proper locale, isalpha('\341') will be
142 true.  But if you read '\341' from a file and store it in a plain
143 char, isalpha(c) may look up character 225, or it may look up
144 character -31.  And the ctype table has no entry at offset -31, so
145 your program will crash.  (If you're lucky.)
147 It is wise to use unsigned char everywhere you possibly can.  This
148 avoids all these problems.  Unfortunately, the routines in <string.h>
149 take plain char arguments, so you have to remember to cast them back
150 and forth - or avoid the use of strxxx() functions, which is probably
151 a good idea anyway.
153 Another common mistake is to use either char or unsigned char to
154 receive the result of getc() or related stdio functions.  They may
155 return EOF, which is outside the range of values representable by
156 char.  If you use char, some legal character value may be confused
157 with EOF, such as '\377' (SMALL LETTER Y WITH UMLAUT, in Latin-1).
158 The correct choice is int.
160 A more subtle version of the same mistake might look like this:
162   unsigned char pushback[NPUSHBACK];
163   int pbidx;
164   #define unget(c) (assert(pbidx < NPUSHBACK), pushback[pbidx++] = (c))
165   #define get(c) (pbidx ? pushback[--pbidx] : getchar())
166   ...
167   unget(EOF);
169 which will mysteriously turn a pushed-back EOF into a SMALL LETTER Y
170 WITH UMLAUT.
173 Other common pitfalls
174 ---------------------
176 o Expecting 'plain' char to be either sign or unsigned extending.
178 o Shifting an item by a negative amount or by greater than or equal to
179   the number of bits in a type (expecting shifts by 32 to be sensible
180   has caused quite a number of bugs at least in the early days).
182 o Expecting ints shifted right to be sign extended.
184 o Modifying the same value twice within one sequence point.
186 o Host vs. target floating point representation, including emitting NaNs
187   and Infinities in a form that the assembler handles.
189 o qsort being an unstable sort function (unstable in the sense that
190   multiple items that sort the same may be sorted in different orders
191   by different qsort functions).
193 o Passing incorrect types to fprintf and friends.
195 o Adding a function declaration for a module declared in another file to
196   a .c file instead of to a .h file.