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

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-old/] [gcc-4.2.2/] [gcc/] [README.Portability] - Diff between revs 154 and 816

Go to most recent revision | Only display areas with differences | Details | Blame | View Log

Rev 154 Rev 816
Copyright (C) 2000, 2003 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
compilers GCC needs to be able to compile on.
compilers GCC needs to be able to compile on.
The problem is that many ISO-standard constructs are not accepted by
The problem is that many ISO-standard constructs are not accepted by
either old or buggy compilers, and we keep getting bitten by them.
either old or buggy compilers, and we keep getting bitten by them.
This knowledge until know has been sparsely spread around, so I
This knowledge until know has been sparsely spread around, so I
thought I'd collect it in one useful place.  Please add and correct
thought I'd collect it in one useful place.  Please add and correct
any problems as you come across them.
any problems as you come across them.
I'm going to start from a base of the ISO C90 standard, since that is
I'm going to start from a base of the ISO C90 standard, since that is
probably what most people code to naturally.  Obviously using
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.
For the complete coding style conventions used in GCC, please read
For the complete coding style conventions used in GCC, please read
http://gcc.gnu.org/codingconventions.html
http://gcc.gnu.org/codingconventions.html
String literals
String literals
---------------
---------------
Irix6 "cc -n32" and OSF4 "cc" have problems with constant string
Irix6 "cc -n32" and OSF4 "cc" have problems with constant string
initializers with parens around it, e.g.
initializers with parens around it, e.g.
const char string[] = ("A string");
const char string[] = ("A string");
This is unfortunate since this is what the GNU gettext macro N_
This is unfortunate since this is what the GNU gettext macro N_
produces.  You need to find a different way to code it.
produces.  You need to find a different way to code it.
Some compilers like MSVC++ have fairly low limits on the maximum
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
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.
may need to break up a long printf statement into many smaller ones.
Empty macro arguments
Empty macro arguments
---------------------
---------------------
ISO C (6.8.3 in the 1990 standard) specifies the following:
ISO C (6.8.3 in the 1990 standard) specifies the following:
If (before argument substitution) any argument consists of no
If (before argument substitution) any argument consists of no
preprocessing tokens, the behavior is undefined.
preprocessing tokens, the behavior is undefined.
This was relaxed by ISO C99, but some older compilers emit an error,
This was relaxed by ISO C99, but some older compilers emit an error,
so code like
so code like
#define foo(x, y) x y
#define foo(x, y) x y
foo (bar, )
foo (bar, )
needs to be coded in some other way.
needs to be coded in some other way.
free and realloc
free and realloc
----------------
----------------
Some implementations crash upon attempts to free or realloc the null
Some implementations crash upon attempts to free or realloc the null
pointer.  Thus if mem might be null, you need to write
pointer.  Thus if mem might be null, you need to write
  if (mem)
  if (mem)
    free (mem);
    free (mem);
Trigraphs
Trigraphs
---------
---------
You weren't going to use them anyway, but some otherwise ISO C
You weren't going to use them anyway, but some otherwise ISO C
compliant compilers do not accept trigraphs.
compliant compilers do not accept trigraphs.
Suffixes on Integer Constants
Suffixes on Integer Constants
-----------------------------
-----------------------------
You should never use a 'l' suffix on integer constants ('L' is fine),
You should never use a 'l' suffix on integer constants ('L' is fine),
since it can easily be confused with the number '1'.
since it can easily be confused with the number '1'.
                        Common Coding Pitfalls
                        Common Coding Pitfalls
                        ======================
                        ======================
errno
errno
-----
-----
errno might be declared as a macro.
errno might be declared as a macro.
Implicit int
Implicit int
------------
------------
In C, the 'int' keyword can often be omitted from type declarations.
In C, the 'int' keyword can often be omitted from type declarations.
For instance, you can write
For instance, you can write
  unsigned variable;
  unsigned variable;
as shorthand for
as shorthand for
  unsigned int variable;
  unsigned int variable;
There are several places where this can cause trouble.  First, suppose
There are several places where this can cause trouble.  First, suppose
'variable' is a long; then you might think
'variable' is a long; then you might think
  (unsigned) variable
  (unsigned) variable
would convert it to unsigned long.  It does not.  It converts to
would convert it to unsigned long.  It does not.  It converts to
unsigned int.  This mostly causes problems on 64-bit platforms, where
unsigned int.  This mostly causes problems on 64-bit platforms, where
long and int are not the same size.
long and int are not the same size.
Second, if you write a function definition with no return type at
Second, if you write a function definition with no return type at
all:
all:
  operate (int a, int b)
  operate (int a, int b)
  {
  {
    ...
    ...
  }
  }
that function is expected to return int, *not* void.  GCC will warn
that function is expected to return int, *not* void.  GCC will warn
about this.
about this.
Implicit function declarations always have return type int.  So if you
Implicit function declarations always have return type int.  So if you
correct the above definition to
correct the above definition to
  void
  void
  operate (int a, int b)
  operate (int a, int b)
  ...
  ...
but operate() is called above its definition, you will get an error
but operate() is called above its definition, you will get an error
about a "type mismatch with previous implicit declaration".  The cure
about a "type mismatch with previous implicit declaration".  The cure
is to prototype all functions at the top of the file, or in an
is to prototype all functions at the top of the file, or in an
appropriate header.
appropriate header.
Char vs unsigned char vs int
Char vs unsigned char vs int
----------------------------
----------------------------
In C, unqualified 'char' may be either signed or unsigned; it is the
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
implementation's choice.  When you are processing 7-bit ASCII, it does
not matter.  But when your program must handle arbitrary binary data,
not matter.  But when your program must handle arbitrary binary data,
or fully 8-bit character sets, you have a problem.  The most obvious
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.
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
For instance, the character '\341' in ISO Latin 1 is SMALL LETTER A
WITH ACUTE ACCENT.  In the proper locale, isalpha('\341') will be
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
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
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
character -31.  And the ctype table has no entry at offset -31, so
your program will crash.  (If you're lucky.)
your program will crash.  (If you're lucky.)
It is wise to use unsigned char everywhere you possibly can.  This
It is wise to use unsigned char everywhere you possibly can.  This
avoids all these problems.  Unfortunately, the routines in 
avoids all these problems.  Unfortunately, the routines in 
take plain char arguments, so you have to remember to cast them back
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
and forth - or avoid the use of strxxx() functions, which is probably
a good idea anyway.
a good idea anyway.
Another common mistake is to use either char or unsigned char to
Another common mistake is to use either char or unsigned char to
receive the result of getc() or related stdio functions.  They may
receive the result of getc() or related stdio functions.  They may
return EOF, which is outside the range of values representable by
return EOF, which is outside the range of values representable by
char.  If you use char, some legal character value may be confused
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).
with EOF, such as '\377' (SMALL LETTER Y WITH UMLAUT, in Latin-1).
The correct choice is int.
The correct choice is int.
A more subtle version of the same mistake might look like this:
A more subtle version of the same mistake might look like this:
  unsigned char pushback[NPUSHBACK];
  unsigned char pushback[NPUSHBACK];
  int pbidx;
  int pbidx;
  #define unget(c) (assert(pbidx < NPUSHBACK), pushback[pbidx++] = (c))
  #define unget(c) (assert(pbidx < NPUSHBACK), pushback[pbidx++] = (c))
  #define get(c) (pbidx ? pushback[--pbidx] : getchar())
  #define get(c) (pbidx ? pushback[--pbidx] : getchar())
  ...
  ...
  unget(EOF);
  unget(EOF);
which will mysteriously turn a pushed-back EOF into a SMALL LETTER Y
which will mysteriously turn a pushed-back EOF into a SMALL LETTER Y
WITH UMLAUT.
WITH UMLAUT.
Other common pitfalls
Other common pitfalls
---------------------
---------------------
o Expecting 'plain' char to be either sign or unsigned extending.
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
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
  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).
  has caused quite a number of bugs at least in the early days).
o Expecting ints shifted right to be sign extended.
o Expecting ints shifted right to be sign extended.
o Modifying the same value twice within one sequence point.
o Modifying the same value twice within one sequence point.
o Host vs. target floating point representation, including emitting NaNs
o Host vs. target floating point representation, including emitting NaNs
  and Infinities in a form that the assembler handles.
  and Infinities in a form that the assembler handles.
o qsort being an unstable sort function (unstable in the sense that
o qsort being an unstable sort function (unstable in the sense that
  multiple items that sort the same may be sorted in different orders
  multiple items that sort the same may be sorted in different orders
  by different qsort functions).
  by different qsort functions).
o Passing incorrect types to fprintf and friends.
o Passing incorrect types to fprintf and friends.
o Adding a function declaration for a module declared in another file to
o Adding a function declaration for a module declared in another file to
  a .c file instead of to a .h file.
  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.