gcc/README.Portability

   1 Copyright (C) 2000, 2003 Free Software Foundation, Inc.
   2
   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.
   6
   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.
  12
  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.
  16
  17 For the complete coding style conventions used in GCC, please read
  18 http://gcc.gnu.org/codingconventions.html
  19
  20
  21 String literals
  22 ---------------
  23
  24 Irix6 "cc -n32" and OSF4 "cc" have problems with constant string
  25 initializers with parens around it, e.g.
  26
  27 const char string[] = ("A string");
  28
  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.
  31
  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.
  35
  36
  37 Empty macro arguments
  38 ---------------------
  39
  40 ISO C (6.8.3 in the 1990 standard) specifies the following:
  41
  42 If (before argument substitution) any argument consists of no
  43 preprocessing tokens, the behavior is undefined.
  44
  45 This was relaxed by ISO C99, but some older compilers emit an error,
  46 so code like
  47
  48 #define foo(x, y) x y
  49 foo (bar, )
  50
  51 needs to be coded in some other way.
  52
  53
  54 Avoid unnecessary test before free
  55 ----------------------------------
  56
  57 Since SunOS 4 stopped being a reasonable portability target,
  58 (which happened around 2007) there has been no need to guard
  59 against "free (NULL)".  Thus, any guard like the following
  60 constitutes a redundant test:
  61
  62   if (P)
  63     free (P);
  64
  65 It is better to avoid the test.[*]
  66 Instead, simply free P, regardless of whether it is NULL.
  67
  68 [*] However, if your profiling exposes a test like this in a
  69 performance-critical loop, say where P is nearly always NULL, and
  70 the cost of calling free on a NULL pointer would be prohibitively
  71 high, consider using __builtin_expect, e.g., like this:
  72
  73   if (__builtin_expect (ptr != NULL, 0))
  74     free (ptr);
  75
  76
  77
  78 Trigraphs
  79 ---------
  80
  81 You weren't going to use them anyway, but some otherwise ISO C
  82 compliant compilers do not accept trigraphs.
  83
  84
  85 Suffixes on Integer Constants
  86 -----------------------------
  87
  88 You should never use a 'l' suffix on integer constants ('L' is fine),
  89 since it can easily be confused with the number '1'.
  90
  91
  92                         Common Coding Pitfalls
  93                         ======================
  94
  95 errno
  96 -----
  97
  98 errno might be declared as a macro.
  99
 100
 101 Implicit int
 102 ------------
 103
 104 In C, the 'int' keyword can often be omitted from type declarations.
 105 For instance, you can write
 106
 107   unsigned variable;
 108
 109 as shorthand for
 110
 111   unsigned int variable;
 112
 113 There are several places where this can cause trouble.  First, suppose
 114 'variable' is a long; then you might think
 115
 116   (unsigned) variable
 117
 118 would convert it to unsigned long.  It does not.  It converts to
 119 unsigned int.  This mostly causes problems on 64-bit platforms, where
 120 long and int are not the same size.
 121
 122 Second, if you write a function definition with no return type at
 123 all:
 124
 125   operate (int a, int b)
 126   {
 127     ...
 128   }
 129
 130 that function is expected to return int, *not* void.  GCC will warn
 131 about this.
 132
 133 Implicit function declarations always have return type int.  So if you
 134 correct the above definition to
 135
 136   void
 137   operate (int a, int b)
 138   ...
 139
 140 but operate() is called above its definition, you will get an error
 141 about a "type mismatch with previous implicit declaration".  The cure
 142 is to prototype all functions at the top of the file, or in an
 143 appropriate header.
 144
 145 Char vs unsigned char vs int
 146 ----------------------------
 147
 148 In C, unqualified 'char' may be either signed or unsigned; it is the
 149 implementation's choice.  When you are processing 7-bit ASCII, it does
 150 not matter.  But when your program must handle arbitrary binary data,
 151 or fully 8-bit character sets, you have a problem.  The most obvious
 152 issue is if you have a look-up table indexed by characters.
 153
 154 For instance, the character '\341' in ISO Latin 1 is SMALL LETTER A
 155 WITH ACUTE ACCENT.  In the proper locale, isalpha('\341') will be
 156 true.  But if you read '\341' from a file and store it in a plain
 157 char, isalpha(c) may look up character 225, or it may look up
 158 character -31.  And the ctype table has no entry at offset -31, so
 159 your program will crash.  (If you're lucky.)
 160
 161 It is wise to use unsigned char everywhere you possibly can.  This
 162 avoids all these problems.  Unfortunately, the routines in <string.h>
 163 take plain char arguments, so you have to remember to cast them back
 164 and forth - or avoid the use of strxxx() functions, which is probably
 165 a good idea anyway.
 166
 167 Another common mistake is to use either char or unsigned char to
 168 receive the result of getc() or related stdio functions.  They may
 169 return EOF, which is outside the range of values representable by
 170 char.  If you use char, some legal character value may be confused
 171 with EOF, such as '\377' (SMALL LETTER Y WITH UMLAUT, in Latin-1).
 172 The correct choice is int.
 173
 174 A more subtle version of the same mistake might look like this:
 175
 176   unsigned char pushback[NPUSHBACK];
 177   int pbidx;
 178   #define unget(c) (assert(pbidx < NPUSHBACK), pushback[pbidx++] = (c))
 179   #define get(c) (pbidx ? pushback[--pbidx] : getchar())
 180   ...
 181   unget(EOF);
 182
 183 which will mysteriously turn a pushed-back EOF into a SMALL LETTER Y
 184 WITH UMLAUT.
 185
 186
 187 Other common pitfalls
 188 ---------------------
 189
 190 o Expecting 'plain' char to be either sign or unsigned extending.
 191
 192 o Shifting an item by a negative amount or by greater than or equal to
 193   the number of bits in a type (expecting shifts by 32 to be sensible
 194   has caused quite a number of bugs at least in the early days).
 195
 196 o Expecting ints shifted right to be sign extended.
 197
 198 o Modifying the same value twice within one sequence point.
 199
 200 o Host vs. target floating point representation, including emitting NaNs
 201   and Infinities in a form that the assembler handles.
 202
 203 o qsort being an unstable sort function (unstable in the sense that
 204   multiple items that sort the same may be sorted in different orders
 205   by different qsort functions).
 206
 207 o Passing incorrect types to fprintf and friends.
 208
 209 o Adding a function declaration for a module declared in another file to
 210   a .c file instead of to a .h file.