You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
249 lines
13 KiB
HTML
249 lines
13 KiB
HTML
4 years ago
|
<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-2015 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.3 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>
|
||
|
|
</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">12.3 Incompatibilities of GCC</h3>
|
||
|
|
|
||
|
|
<p><a name="index-incompatibilities-of-GCC-4245"></a><a name="index-traditional-4246"></a>
|
||
|
|
There are several noteworthy incompatibilities between GNU C and K&R
|
||
|
|
(non-ISO) versions of C.
|
||
|
|
|
||
|
|
|
||
|
|
<a name="index-string-constants-4247"></a>
|
||
|
|
<a name="index-read_002donly-strings-4248"></a>
|
||
|
|
<a name="index-shared-strings-4249"></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-4250"></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-4251"></a><a name="index-g_t_0040code_007bfscanf_007d_002c-and-constant-strings-4252"></a><a name="index-g_t_0040code_007bscanf_007d_002c-and-constant-strings-4253"></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-4254"></a><a name="index-g_t_0040code_007blongjmp_007d-incompatibilities-4255"></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-4256"></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-4257"></a><a name="index-scope-of-external-declarations-4258"></a><a name="index-declaration-scope-4259"></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-4260"></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-4261"></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-4262"></a><a name="index-g_t_0040code_007b_0027_007d-4263"></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-4264"></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-4265"></a><a name="index-unions-4266"></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-4267"></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-4268"></a><a name="index-preprocessing-numbers-4269"></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>
|
||
|
|
|