Commit ced2ad76 by Matt Kraai Committed by Matt Kraai

README.Portability: Move to a new section and obsolete K+R portability issues.

	* README.Portability: Move to a new section and obsolete K+R
	portability issues.

From-SVN: r65818
parent 07015444
2003-04-19 Matt Kraai <kraai@alumni.cmu.edu>
* README.Portability: Move to a new section and obsolete K+R
portability issues.
Sat Apr 19 14:56:17 CEST 2003 Jan Hubicka <jh@suse.cz> Sat Apr 19 14:56:17 CEST 2003 Jan Hubicka <jh@suse.cz>
* rtlanal.c (subreg_offset_representable_p): Fix call of * rtlanal.c (subreg_offset_representable_p): Fix call of
......
Copyright (C) 2000 Free Software Foundation, Inc. Copyright (C) 2000, 2003 Free Software Foundation, Inc.
This file is intended to contain a few notes about writing C code This file is intended to contain a few notes about writing C code
within GCC so that it compiles without error on the full range of within GCC so that it compiles without error on the full range of
...@@ -15,17 +15,198 @@ probably what most people code to naturally. Obviously using ...@@ -15,17 +15,198 @@ probably what most people code to naturally. Obviously using
constructs introduced after that is not a good idea. constructs introduced after that is not a good idea.
The first section of this file deals strictly with portability issues, The first section of this file deals strictly with portability issues,
the second with common coding pitfalls. the second with common coding pitfalls, and the third with obsolete
K+R portability issues.
Portability Issues Portability Issues
================== ==================
String literals
---------------
Some SGI compilers choke on the parentheses in:-
const char string[] = ("A string");
This is unfortunate since this is what the GNU gettext macro N_
produces. You need to find a different way to code it.
Some compilers like MSVC++ have fairly low limits on the maximum
length of a string literal; 509 is the lowest we've come across. You
may need to break up a long printf statement into many smaller ones.
Empty macro arguments
---------------------
ISO C (6.8.3 in the 1990 standard) specifies the following:
If (before argument substitution) any argument consists of no
preprocessing tokens, the behavior is undefined.
This was relaxed by ISO C99, but some older compilers emit an error,
so code like
#define foo(x, y) x y
foo (bar, )
needs to be coded in some other way.
free and realloc
----------------
Some implementations crash upon attempts to free or realloc the null
pointer. Thus if mem might be null, you need to write
if (mem)
free (mem);
Trigraphs
---------
You weren't going to use them anyway, but some otherwise ISO C
compliant compilers do not accept trigraphs.
Suffixes on Integer Constants
-----------------------------
You should never use a 'l' suffix on integer constants ('L' is fine),
since it can easily be confused with the number '1'.
Common Coding Pitfalls
======================
errno
-----
errno might be declared as a macro.
Implicit int
------------
In C, the 'int' keyword can often be omitted from type declarations.
For instance, you can write
unsigned variable;
as shorthand for
unsigned int variable;
There are several places where this can cause trouble. First, suppose
'variable' is a long; then you might think
(unsigned) variable
would convert it to unsigned long. It does not. It converts to
unsigned int. This mostly causes problems on 64-bit platforms, where
long and int are not the same size.
Second, if you write a function definition with no return type at
all:
operate (int a, int b)
{
...
}
that function is expected to return int, *not* void. GCC will warn
about this.
Implicit function declarations always have return type int. So if you
correct the above definition to
void
operate (int a, int b)
...
but operate() is called above its definition, you will get an error
about a "type mismatch with previous implicit declaration". The cure
is to prototype all functions at the top of the file, or in an
appropriate header.
Char vs unsigned char vs int
----------------------------
In C, unqualified 'char' may be either signed or unsigned; it is the
implementation's choice. When you are processing 7-bit ASCII, it does
not matter. But when your program must handle arbitrary binary data,
or fully 8-bit character sets, you have a problem. The most obvious
issue is if you have a look-up table indexed by characters.
For instance, the character '\341' in ISO Latin 1 is SMALL LETTER A
WITH ACUTE ACCENT. In the proper locale, isalpha('\341') will be
true. But if you read '\341' from a file and store it in a plain
char, isalpha(c) may look up character 225, or it may look up
character -31. And the ctype table has no entry at offset -31, so
your program will crash. (If you're lucky.)
It is wise to use unsigned char everywhere you possibly can. This
avoids all these problems. Unfortunately, the routines in <string.h>
take plain char arguments, so you have to remember to cast them back
and forth - or avoid the use of strxxx() functions, which is probably
a good idea anyway.
Another common mistake is to use either char or unsigned char to
receive the result of getc() or related stdio functions. They may
return EOF, which is outside the range of values representable by
char. If you use char, some legal character value may be confused
with EOF, such as '\377' (SMALL LETTER Y WITH UMLAUT, in Latin-1).
The correct choice is int.
A more subtle version of the same mistake might look like this:
unsigned char pushback[NPUSHBACK];
int pbidx;
#define unget(c) (assert(pbidx < NPUSHBACK), pushback[pbidx++] = (c))
#define get(c) (pbidx ? pushback[--pbidx] : getchar())
...
unget(EOF);
which will mysteriously turn a pushed-back EOF into a SMALL LETTER Y
WITH UMLAUT.
Other common pitfalls
---------------------
o Expecting 'plain' char to be either sign or unsigned extending
o Shifting an item by a negative amount or by greater than or equal to
the number of bits in a type (expecting shifts by 32 to be sensible
has caused quite a number of bugs at least in the early days).
o Expecting ints shifted right to be sign extended.
o Modifying the same value twice within one sequence point.
o Host vs. target floating point representation, including emitting NaNs
and Infinities in a form that the assembler handles.
o qsort being an unstable sort function (unstable in the sense that
multiple items that sort the same may be sorted in different orders
by different qsort functions).
o Passing incorrect types to fprintf and friends.
o Adding a function declaration for a module declared in another file to
a .c file instead of to a .h file.
K+R Portability Issues
======================
Unary + Unary +
------- -------
K+R C compilers and preprocessors have no notion of unary '+'. Thus K+R C compilers and preprocessors have no notion of unary '+'. Thus
the following code snippet contains 2 portability problems. the following code snippet contained 2 portability problems.
int x = +2; /* int x = 2; */ int x = +2; /* int x = 2; */
#if +1 /* #if 1 */ #if +1 /* #if 1 */
...@@ -42,62 +223,34 @@ a K+R one. Thus ...@@ -42,62 +223,34 @@ a K+R one. Thus
free ((void *) h->value.expansion); free ((void *) h->value.expansion);
should be written should have been written
free ((PTR) h->value.expansion); free ((PTR) h->value.expansion);
Further, an initial investigation indicates that pointers to functions Further, an initial investigation indicates that pointers to functions
returning void are okay. Thus the example given by "Calling functions returning void were okay. Thus the example given by "Calling
through pointers to functions" below appears not to cause a problem. functions through pointers to functions" below appeared not to cause a
problem.
String literals String literals
--------------- ---------------
Some SGI compilers choke on the parentheses in:-
const char string[] = ("A string");
This is unfortunate since this is what the GNU gettext macro N_
produces. You need to find a different way to code it.
K+R C did not allow concatenation of string literals like K+R C did not allow concatenation of string literals like
"This is a " "single string literal". "This is a " "single string literal".
Moreover, some compilers like MSVC++ have fairly low limits on the
maximum length of a string literal; 509 is the lowest we've come
across. You may need to break up a long printf statement into many
smaller ones.
Empty macro arguments
---------------------
ISO C (6.8.3 in the 1990 standard) specifies the following:
If (before argument substitution) any argument consists of no
preprocessing tokens, the behavior is undefined.
This was relaxed by ISO C99, but some older compilers emit an error,
so code like
#define foo(x, y) x y
foo (bar, )
needs to be coded in some other way.
signed keyword signed keyword
-------------- --------------
The signed keyword did not exist in K+R compilers; it was introduced The signed keyword did not exist in K+R compilers; it was introduced
in ISO C89, so you cannot use it. In both K+R and standard C, in ISO C89, so you could not use it. In both K+R and standard C,
unqualified char and bitfields may be signed or unsigned. There is no unqualified char and bitfields may be signed or unsigned. There is no
way to portably declare signed chars or signed bitfields. way to portably declare signed chars or signed bitfields.
All other arithmetic types are signed unless you use the 'unsigned' All other arithmetic types are signed unless you use the 'unsigned'
qualifier. For instance, it is safe to write qualifier. For instance, it was safe to write
short paramc; short paramc;
...@@ -106,7 +259,7 @@ instead of ...@@ -106,7 +259,7 @@ instead of
signed short paramc; signed short paramc;
If you have an algorithm that depends on signed char or signed If you have an algorithm that depends on signed char or signed
bitfields, you must find another way to write it before it can be bitfields, you had to find another way to write it before it could be
integrated into GCC. integrated into GCC.
...@@ -114,10 +267,10 @@ Function prototypes ...@@ -114,10 +267,10 @@ Function prototypes
------------------- -------------------
You need to provide a function prototype for every function before you You need to provide a function prototype for every function before you
use it, and functions must be defined K+R style. The function use it, and functions had to be defined K+R style. The function
prototype should use the PARAMS macro, which takes a single argument. prototype should have used the PARAMS macro, which takes a single
Therefore the parameter list must be enclosed in parentheses. For argument. Therefore the parameter list had to be enclosed in
example, parentheses. For example,
int myfunc PARAMS ((double, int *)); int myfunc PARAMS ((double, int *));
...@@ -129,7 +282,7 @@ myfunc (var1, var2) ...@@ -129,7 +282,7 @@ myfunc (var1, var2)
... ...
} }
This implies that if the function takes no arguments, it should be This implies that if the function takes no arguments, it had to be
declared and defined as follows: declared and defined as follows:
int myfunc PARAMS ((void)); int myfunc PARAMS ((void));
...@@ -140,7 +293,7 @@ myfunc () ...@@ -140,7 +293,7 @@ myfunc ()
... ...
} }
You also need to use PARAMS when referring to function protypes in You also had to use PARAMS when referring to function protypes in
other circumstances, for example see "Calling functions through other circumstances, for example see "Calling functions through
pointers to functions" below. pointers to functions" below.
...@@ -161,7 +314,7 @@ cpp_ice VPARAMS ((cpp_reader *pfile, const char *msgid, ...)) ...@@ -161,7 +314,7 @@ cpp_ice VPARAMS ((cpp_reader *pfile, const char *msgid, ...))
See ansidecl.h for the definitions of the above macros and more. See ansidecl.h for the definitions of the above macros and more.
One aspect of using K+R style function declarations, is you cannot One aspect of using K+R style function declarations, is you could not
have arguments whose types are char, short, or float, since without have arguments whose types are char, short, or float, since without
prototypes (ie, K+R rules), these types are promoted to int, int, and prototypes (ie, K+R rules), these types are promoted to int, int, and
double respectively. double respectively.
...@@ -176,7 +329,7 @@ example ...@@ -176,7 +329,7 @@ example
typedef void (* cl_directive_handler) PARAMS ((cpp_reader *, const char *)); typedef void (* cl_directive_handler) PARAMS ((cpp_reader *, const char *));
*p->handler (pfile, p->arg); *p->handler (pfile, p->arg);
needs to become had to become
(*p->handler) (pfile, p->arg); (*p->handler) (pfile, p->arg);
...@@ -202,16 +355,17 @@ compilers x should not have spaces around it. ...@@ -202,16 +355,17 @@ compilers x should not have spaces around it.
Passing structures by value Passing structures by value
--------------------------- ---------------------------
Avoid passing structures by value, either to or from functions. It You had to avoid passing structures by value, either to or from
seems some K+R compilers handle this differently or not at all. functions. It seems some K+R compilers handle this differently or not
at all.
Enums Enums
----- -----
In K+R C, you have to cast enum types to use them as integers, and In K+R C, you had to cast enum types to use them as integers, and some
some compilers in particular give lots of warnings for using an enum compilers in particular give lots of warnings for using an enum as an
as an array index. array index.
Bitfields Bitfields
...@@ -222,20 +376,10 @@ were defined (i.e. unsigned char, unsigned short, unsigned long. ...@@ -222,20 +376,10 @@ were defined (i.e. unsigned char, unsigned short, unsigned long.
Using plain int/short/long was not allowed). Using plain int/short/long was not allowed).
free and realloc
----------------
Some implementations crash upon attempts to free or realloc the null
pointer. Thus if mem might be null, you need to write
if (mem)
free (mem);
Reserved Keywords Reserved Keywords
----------------- -----------------
K+R C has "entry" as a reserved keyword, so you should not use it for K+R C has "entry" as a reserved keyword, so you had to not use it for
your variable names. your variable names.
...@@ -248,144 +392,10 @@ int is done as an unsigned comparison in K+R (since unsigned char ...@@ -248,144 +392,10 @@ int is done as an unsigned comparison in K+R (since unsigned char
promotes to unsigned) while it is signed in ISO (since all of the promotes to unsigned) while it is signed in ISO (since all of the
values in unsigned char fit in an int, it promotes to int). values in unsigned char fit in an int, it promotes to int).
Trigraphs
---------
You weren't going to use them anyway, but trigraphs were not defined
in K+R C, and some otherwise ISO C compliant compilers do not accept
them.
Suffixes on Integer Constants Suffixes on Integer Constants
----------------------------- -----------------------------
K+R C did not accept a 'u' suffix on integer constants. If you want K+R C did not accept a 'u' suffix on integer constants. If you wanted
to declare a constant to be be unsigned, you must use an explicit to declare a constant to be be unsigned, you had to use an explicit
cast. cast.
You should never use a 'l' suffix on integer constants ('L' is fine),
since it can easily be confused with the number '1'.
Common Coding Pitfalls
======================
errno
-----
errno might be declared as a macro.
Implicit int
------------
In C, the 'int' keyword can often be omitted from type declarations.
For instance, you can write
unsigned variable;
as shorthand for
unsigned int variable;
There are several places where this can cause trouble. First, suppose
'variable' is a long; then you might think
(unsigned) variable
would convert it to unsigned long. It does not. It converts to
unsigned int. This mostly causes problems on 64-bit platforms, where
long and int are not the same size.
Second, if you write a function definition with no return type at
all:
operate (a, b)
int a, b;
{
...
}
that function is expected to return int, *not* void. GCC will warn
about this. K+R C has no problem with 'void' as a return type, so you
need not worry about that.
Implicit function declarations always have return type int. So if you
correct the above definition to
void
operate (a, b)
int a, b;
...
but operate() is called above its definition, you will get an error
about a "type mismatch with previous implicit declaration". The cure
is to prototype all functions at the top of the file, or in an
appropriate header.
Char vs unsigned char vs int
----------------------------
In C, unqualified 'char' may be either signed or unsigned; it is the
implementation's choice. When you are processing 7-bit ASCII, it does
not matter. But when your program must handle arbitrary binary data,
or fully 8-bit character sets, you have a problem. The most obvious
issue is if you have a look-up table indexed by characters.
For instance, the character '\341' in ISO Latin 1 is SMALL LETTER A
WITH ACUTE ACCENT. In the proper locale, isalpha('\341') will be
true. But if you read '\341' from a file and store it in a plain
char, isalpha(c) may look up character 225, or it may look up
character -31. And the ctype table has no entry at offset -31, so
your program will crash. (If you're lucky.)
It is wise to use unsigned char everywhere you possibly can. This
avoids all these problems. Unfortunately, the routines in <string.h>
take plain char arguments, so you have to remember to cast them back
and forth - or avoid the use of strxxx() functions, which is probably
a good idea anyway.
Another common mistake is to use either char or unsigned char to
receive the result of getc() or related stdio functions. They may
return EOF, which is outside the range of values representable by
char. If you use char, some legal character value may be confused
with EOF, such as '\377' (SMALL LETTER Y WITH UMLAUT, in Latin-1).
The correct choice is int.
A more subtle version of the same mistake might look like this:
unsigned char pushback[NPUSHBACK];
int pbidx;
#define unget(c) (assert(pbidx < NPUSHBACK), pushback[pbidx++] = (c))
#define get(c) (pbidx ? pushback[--pbidx] : getchar())
...
unget(EOF);
which will mysteriously turn a pushed-back EOF into a SMALL LETTER Y
WITH UMLAUT.
Other common pitfalls
---------------------
o Expecting 'plain' char to be either sign or unsigned extending
o Shifting an item by a negative amount or by greater than or equal to
the number of bits in a type (expecting shifts by 32 to be sensible
has caused quite a number of bugs at least in the early days).
o Expecting ints shifted right to be sign extended.
o Modifying the same value twice within one sequence point.
o Host vs. target floating point representation, including emitting NaNs
and Infinities in a form that the assembler handles.
o qsort being an unstable sort function (unstable in the sense that
multiple items that sort the same may be sorted in different orders
by different qsort functions).
o Passing incorrect types to fprintf and friends.
o Adding a function declaration for a module declared in another file to
a .c file instead of to a .h file.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment