OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-dev/] [or1k-gcc/] [gcc/] [README.Portability] - Blame information for rev 747

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 684 jeremybenn
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 
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.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.