| <html lang="en"> |
| <head> |
| <title>Incompatibilities - Using the GNU Compiler Collection (GCC)</title> |
| <meta http-equiv="Content-Type" content="text/html"> |
| <meta name="description" content="Using the GNU Compiler Collection (GCC)"> |
| <meta name="generator" content="makeinfo 4.13"> |
| <link title="Top" rel="start" href="index.html#Top"> |
| <link rel="up" href="Trouble.html#Trouble" title="Trouble"> |
| <link rel="prev" href="Interoperation.html#Interoperation" title="Interoperation"> |
| <link rel="next" href="Fixed-Headers.html#Fixed-Headers" title="Fixed Headers"> |
| <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> |
| <!-- |
| Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, |
| 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, |
| 2008 Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.2 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being ``Funding Free Software'', the Front-Cover |
| Texts being (a) (see below), and with the Back-Cover Texts being (b) |
| (see below). A copy of the license is included in the section entitled |
| ``GNU Free Documentation License''. |
| |
| (a) The FSF's Front-Cover Text is: |
| |
| A GNU Manual |
| |
| (b) The FSF's Back-Cover Text is: |
| |
| You have freedom to copy and modify this GNU Manual, like GNU |
| software. Copies published by the Free Software Foundation raise |
| funds for GNU development.--> |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| <style type="text/css"><!-- |
| pre.display { font-family:inherit } |
| pre.format { font-family:inherit } |
| pre.smalldisplay { font-family:inherit; font-size:smaller } |
| pre.smallformat { font-family:inherit; font-size:smaller } |
| pre.smallexample { font-size:smaller } |
| pre.smalllisp { font-size:smaller } |
| span.sc { font-variant:small-caps } |
| span.roman { font-family:serif; font-weight:normal; } |
| span.sansserif { font-family:sans-serif; font-weight:normal; } |
| --></style> |
| <link rel="stylesheet" type="text/css" href="../cs.css"> |
| </head> |
| <body> |
| <div class="node"> |
| <a name="Incompatibilities"></a> |
| <p> |
| Next: <a rel="next" accesskey="n" href="Fixed-Headers.html#Fixed-Headers">Fixed Headers</a>, |
| Previous: <a rel="previous" accesskey="p" href="Interoperation.html#Interoperation">Interoperation</a>, |
| Up: <a rel="up" accesskey="u" href="Trouble.html#Trouble">Trouble</a> |
| <hr> |
| </div> |
| |
| <h3 class="section">11.4 Incompatibilities of GCC</h3> |
| |
| <p><a name="index-incompatibilities-of-GCC-3200"></a><a name="index-traditional-3201"></a> |
| There are several noteworthy incompatibilities between GNU C and K&R |
| (non-ISO) versions of C. |
| |
| |
| <a name="index-string-constants-3202"></a> |
| <a name="index-read_002donly-strings-3203"></a> |
| <a name="index-shared-strings-3204"></a> |
| <ul><li>GCC normally makes string constants read-only. If several |
| identical-looking string constants are used, GCC stores only one |
| copy of the string. |
| |
| <p><a name="index-g_t_0040code_007bmktemp_007d_002c-and-constant-strings-3205"></a>One consequence is that you cannot call <code>mktemp</code> with a string |
| constant argument. The function <code>mktemp</code> always alters the |
| string its argument points to. |
| |
| <p><a name="index-g_t_0040code_007bsscanf_007d_002c-and-constant-strings-3206"></a><a name="index-g_t_0040code_007bfscanf_007d_002c-and-constant-strings-3207"></a><a name="index-g_t_0040code_007bscanf_007d_002c-and-constant-strings-3208"></a>Another consequence is that <code>sscanf</code> does not work on some very |
| old systems when passed a string constant as its format control string |
| or input. This is because <code>sscanf</code> incorrectly tries to write |
| into the string constant. Likewise <code>fscanf</code> and <code>scanf</code>. |
| |
| <p>The solution to these problems is to change the program to use |
| <code>char</code>-array variables with initialization strings for these |
| purposes instead of string constants. |
| |
| <li><code>-2147483648</code> is positive. |
| |
| <p>This is because 2147483648 cannot fit in the type <code>int</code>, so |
| (following the ISO C rules) its data type is <code>unsigned long int</code>. |
| Negating this value yields 2147483648 again. |
| |
| <li>GCC does not substitute macro arguments when they appear inside of |
| string constants. For example, the following macro in GCC |
| |
| <pre class="smallexample"> #define foo(a) "a" |
| </pre> |
| <p class="noindent">will produce output <code>"a"</code> regardless of what the argument <var>a</var> is. |
| |
| <p><a name="index-g_t_0040code_007bsetjmp_007d-incompatibilities-3209"></a><a name="index-g_t_0040code_007blongjmp_007d-incompatibilities-3210"></a><li>When you use <code>setjmp</code> and <code>longjmp</code>, the only automatic |
| variables guaranteed to remain valid are those declared |
| <code>volatile</code>. This is a consequence of automatic register |
| allocation. Consider this function: |
| |
| <pre class="smallexample"> jmp_buf j; |
| |
| foo () |
| { |
| int a, b; |
| |
| a = fun1 (); |
| if (setjmp (j)) |
| return a; |
| |
| a = fun2 (); |
| /* <code>longjmp (j)</code><span class="roman"> may occur in </span><code>fun3</code><span class="roman">.</span> */ |
| return a + fun3 (); |
| } |
| </pre> |
| <p>Here <code>a</code> may or may not be restored to its first value when the |
| <code>longjmp</code> occurs. If <code>a</code> is allocated in a register, then |
| its first value is restored; otherwise, it keeps the last value stored |
| in it. |
| |
| <p><a name="index-W-3211"></a>If you use the <samp><span class="option">-W</span></samp> option with the <samp><span class="option">-O</span></samp> option, you will |
| get a warning when GCC thinks such a problem might be possible. |
| |
| <li>Programs that use preprocessing directives in the middle of macro |
| arguments do not work with GCC. For example, a program like this |
| will not work: |
| |
| <pre class="smallexample"> foobar ( |
| #define luser |
| hack) |
| </pre> |
| <p>ISO C does not permit such a construct. |
| |
| <li>K&R compilers allow comments to cross over an inclusion boundary |
| (i.e. started in an include file and ended in the including file). |
| |
| <p><a name="index-external-declaration-scope-3212"></a><a name="index-scope-of-external-declarations-3213"></a><a name="index-declaration-scope-3214"></a><li>Declarations of external variables and functions within a block apply |
| only to the block containing the declaration. In other words, they |
| have the same scope as any other declaration in the same place. |
| |
| <p>In some other C compilers, an <code>extern</code> declaration affects all the |
| rest of the file even if it happens within a block. |
| |
| <li>In traditional C, you can combine <code>long</code>, etc., with a typedef name, |
| as shown here: |
| |
| <pre class="smallexample"> typedef int foo; |
| typedef long foo bar; |
| </pre> |
| <p>In ISO C, this is not allowed: <code>long</code> and other type modifiers |
| require an explicit <code>int</code>. |
| |
| <p><a name="index-typedef-names-as-function-parameters-3215"></a><li>PCC allows typedef names to be used as function parameters. |
| |
| <li>Traditional C allows the following erroneous pair of declarations to |
| appear together in a given scope: |
| |
| <pre class="smallexample"> typedef int foo; |
| typedef foo foo; |
| </pre> |
| <li>GCC treats all characters of identifiers as significant. According to |
| K&R-1 (2.2), “No more than the first eight characters are significant, |
| although more may be used.”. Also according to K&R-1 (2.2), “An |
| identifier is a sequence of letters and digits; the first character must |
| be a letter. The underscore _ counts as a letter.”, but GCC also |
| allows dollar signs in identifiers. |
| |
| <p><a name="index-whitespace-3216"></a><li>PCC allows whitespace in the middle of compound assignment operators |
| such as ‘<samp><span class="samp">+=</span></samp>’. GCC, following the ISO standard, does not |
| allow this. |
| |
| <p><a name="index-apostrophes-3217"></a><a name="index-g_t_0027-3218"></a><li>GCC complains about unterminated character constants inside of |
| preprocessing conditionals that fail. Some programs have English |
| comments enclosed in conditionals that are guaranteed to fail; if these |
| comments contain apostrophes, GCC will probably report an error. For |
| example, this code would produce an error: |
| |
| <pre class="smallexample"> #if 0 |
| You can't expect this to work. |
| #endif |
| </pre> |
| <p>The best solution to such a problem is to put the text into an actual |
| C comment delimited by ‘<samp><span class="samp">/*...*/</span></samp>’. |
| |
| <li>Many user programs contain the declaration ‘<samp><span class="samp">long time ();</span></samp>’. In the |
| past, the system header files on many systems did not actually declare |
| <code>time</code>, so it did not matter what type your program declared it to |
| return. But in systems with ISO C headers, <code>time</code> is declared to |
| return <code>time_t</code>, and if that is not the same as <code>long</code>, then |
| ‘<samp><span class="samp">long time ();</span></samp>’ is erroneous. |
| |
| <p>The solution is to change your program to use appropriate system headers |
| (<code><time.h></code> on systems with ISO C headers) and not to declare |
| <code>time</code> if the system header files declare it, or failing that to |
| use <code>time_t</code> as the return type of <code>time</code>. |
| |
| <p><a name="index-g_t_0040code_007bfloat_007d-as-function-value-type-3219"></a><li>When compiling functions that return <code>float</code>, PCC converts it to |
| a double. GCC actually returns a <code>float</code>. If you are concerned |
| with PCC compatibility, you should declare your functions to return |
| <code>double</code>; you might as well say what you mean. |
| |
| <p><a name="index-structures-3220"></a><a name="index-unions-3221"></a><li>When compiling functions that return structures or unions, GCC |
| output code normally uses a method different from that used on most |
| versions of Unix. As a result, code compiled with GCC cannot call |
| a structure-returning function compiled with PCC, and vice versa. |
| |
| <p>The method used by GCC is as follows: a structure or union which is |
| 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union |
| with any other size is stored into an address supplied by the caller |
| (usually in a special, fixed register, but on some machines it is passed |
| on the stack). The target hook <code>TARGET_STRUCT_VALUE_RTX</code> |
| tells GCC where to pass this address. |
| |
| <p>By contrast, PCC on most target machines returns structures and unions |
| of any size by copying the data into an area of static storage, and then |
| returning the address of that storage as if it were a pointer value. |
| The caller must copy the data from that memory area to the place where |
| the value is wanted. GCC does not use this method because it is |
| slower and nonreentrant. |
| |
| <p>On some newer machines, PCC uses a reentrant convention for all |
| structure and union returning. GCC on most of these machines uses a |
| compatible convention when returning structures and unions in memory, |
| but still returns small structures and unions in registers. |
| |
| <p><a name="index-fpcc_002dstruct_002dreturn-3222"></a>You can tell GCC to use a compatible convention for all structure and |
| union returning with the option <samp><span class="option">-fpcc-struct-return</span></samp>. |
| |
| <p><a name="index-preprocessing-tokens-3223"></a><a name="index-preprocessing-numbers-3224"></a><li>GCC complains about program fragments such as ‘<samp><span class="samp">0x74ae-0x4000</span></samp>’ |
| which appear to be two hexadecimal constants separated by the minus |
| operator. Actually, this string is a single <dfn>preprocessing token</dfn>. |
| Each such token must correspond to one token in C. Since this does not, |
| GCC prints an error message. Although it may appear obvious that what |
| is meant is an operator and two values, the ISO C standard specifically |
| requires that this be treated as erroneous. |
| |
| <p>A <dfn>preprocessing token</dfn> is a <dfn>preprocessing number</dfn> if it |
| begins with a digit and is followed by letters, underscores, digits, |
| periods and ‘<samp><span class="samp">e+</span></samp>’, ‘<samp><span class="samp">e-</span></samp>’, ‘<samp><span class="samp">E+</span></samp>’, ‘<samp><span class="samp">E-</span></samp>’, ‘<samp><span class="samp">p+</span></samp>’, |
| ‘<samp><span class="samp">p-</span></samp>’, ‘<samp><span class="samp">P+</span></samp>’, or ‘<samp><span class="samp">P-</span></samp>’ character sequences. (In strict C90 |
| mode, the sequences ‘<samp><span class="samp">p+</span></samp>’, ‘<samp><span class="samp">p-</span></samp>’, ‘<samp><span class="samp">P+</span></samp>’ and ‘<samp><span class="samp">P-</span></samp>’ cannot |
| appear in preprocessing numbers.) |
| |
| <p>To make the above program fragment valid, place whitespace in front of |
| the minus sign. This whitespace will end the preprocessing number. |
| </ul> |
| |
| </body></html> |
| |
