gcc.texi

来自「GCC编译器源代码」· TEXI 代码 · 共 1,739 行 · 第 1/5 页

Many user programs contain the declaration @samp{long time ();}.  In the
past, the system header files on many systems did not actually declare
@code{time}, so it did not matter what type your program declared it to
return.  But in systems with ANSI C headers, @code{time} is declared to
return @code{time_t}, and if that is not the same as @code{long}, then
@samp{long time ();} is erroneous.

The solution is to change your program to use @code{time_t} as the return
type of @code{time}.

@cindex @code{float} as function value type
@item
When compiling functions that return @code{float}, PCC converts it to
a double.  GNU CC actually returns a @code{float}.  If you are concerned
with PCC compatibility, you should declare your functions to return
@code{double}; you might as well say what you mean.

@cindex structures
@cindex unions
@item
When compiling functions that return structures or unions, GNU CC
output code normally uses a method different from that used on most
versions of Unix.  As a result, code compiled with GNU CC cannot call
a structure-returning function compiled with PCC, and vice versa.

The method used by GNU CC 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 machine-description macros @code{STRUCT_VALUE} and
@code{STRUCT_INCOMING_VALUE} tell GNU CC where to pass this address.

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.  GNU CC does not use this method because it is
slower and nonreentrant.

On some newer machines, PCC uses a reentrant convention for all
structure and union returning.  GNU CC 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.

You can tell GNU CC to use a compatible convention for all structure and
union returning with the option @samp{-fpcc-struct-return}.

@cindex preprocessing tokens
@cindex preprocessing numbers
@item
GNU C complains about program fragments such as @samp{0x74ae-0x4000}
which appear to be two hexadecimal constants separated by the minus
operator.  Actually, this string is a single @dfn{preprocessing token}.
Each such token must correspond to one token in C.  Since this does not,
GNU C prints an error message.  Although it may appear obvious that what
is meant is an operator and two values, the ANSI C standard specifically
requires that this be treated as erroneous.

A @dfn{preprocessing token} is a @dfn{preprocessing number} if it
begins with a digit and is followed by letters, underscores, digits,
periods and @samp{e+}, @samp{e-}, @samp{E+}, or @samp{E-} character
sequences.

To make the above program fragment valid, place whitespace in front of
the minus sign.  This whitespace will end the preprocessing number.
@end itemize

@node Fixed Headers
@section Fixed Header Files

GNU CC needs to install corrected versions of some system header files.
This is because most target systems have some header files that won't
work with GNU CC unless they are changed.  Some have bugs, some are
incompatible with ANSI C, and some depend on special features of other
compilers.

Installing GNU CC automatically creates and installs the fixed header
files, by running a program called @code{fixincludes} (or for certain
targets an alternative such as @code{fixinc.svr4}).  Normally, you
don't need to pay attention to this.  But there are cases where it
doesn't do the right thing automatically.

@itemize @bullet
@item
If you update the system's header files, such as by installing a new
system version, the fixed header files of GNU CC are not automatically
updated.  The easiest way to update them is to reinstall GNU CC.  (If
you want to be clever, look in the makefile and you can find a
shortcut.)

@item
On some systems, in particular SunOS 4, header file directories contain
machine-specific symbolic links in certain places.  This makes it
possible to share most of the header files among hosts running the
same version of SunOS 4 on different machine models.

The programs that fix the header files do not understand this special
way of using symbolic links; therefore, the directory of fixed header
files is good only for the machine model used to build it.

In SunOS 4, only programs that look inside the kernel will notice the
difference between machine models.  Therefore, for most purposes, you
need not be concerned about this.

It is possible to make separate sets of fixed header files for the
different machine models, and arrange a structure of symbolic links so
as to use the proper set, but you'll have to do this by hand.

@item
On Lynxos, GNU CC by default does not fix the header files.  This is
because bugs in the shell cause the @code{fixincludes} script to fail.

This means you will encounter problems due to bugs in the system header
files.  It may be no comfort that they aren't GNU CC's fault, but it
does mean that there's nothing for us to do about them.
@end itemize

@node Standard Libraries
@section Standard Libraries

GNU CC by itself attempts to be what the ISO/ANSI C standard calls a
@dfn{conforming freestanding implementation}.  This means all ANSI
C language features are available, as well as the contents of
@file{float.h}, @file{limits.h}, @file{stdarg.h}, and
@file{stddef.h}.  The rest of the C library is supplied by the
vendor of the operating system.  If that C library doesn't conform to
the C standards, then your programs might get warnings (especially when
using @samp{-Wall}) that you don't expect.

For example, the @code{sprintf} function on SunOS 4.1.3 returns
@code{char *} while the C standard says that @code{sprintf} returns an
@code{int}.  The @code{fixincludes} program could make the prototype for
this function match the Standard, but that would be wrong, since the
function will still return @code{char *}.

If you need a Standard compliant library, then you need to find one, as
GNU CC does not provide one.  The GNU C library (called @code{glibc})
has been ported to a number of operating systems, and provides ANSI/ISO,
POSIX, BSD and SystemV compatibility.  You could also ask your operating
system vendor if newer libraries are available.

@node Disappointments
@section Disappointments and Misunderstandings

These problems are perhaps regrettable, but we don't know any practical
way around them.

@itemize @bullet
@item
Certain local variables aren't recognized by debuggers when you compile
with optimization.

This occurs because sometimes GNU CC optimizes the variable out of
existence.  There is no way to tell the debugger how to compute the
value such a variable ``would have had'', and it is not clear that would
be desirable anyway.  So GNU CC simply does not mention the eliminated
variable when it writes debugging information.

You have to expect a certain amount of disagreement between the
executable and your source code, when you use optimization.

@cindex conflicting types
@cindex scope of declaration
@item
Users often think it is a bug when GNU CC reports an error for code
like this:

@example
int foo (struct mumble *);

struct mumble @{ @dots{} @};

int foo (struct mumble *x)
@{ @dots{} @}
@end example

This code really is erroneous, because the scope of @code{struct
mumble} in the prototype is limited to the argument list containing it.
It does not refer to the @code{struct mumble} defined with file scope
immediately below---they are two unrelated types with similar names in
different scopes.

But in the definition of @code{foo}, the file-scope type is used
because that is available to be inherited.  Thus, the definition and
the prototype do not match, and you get an error.

This behavior may seem silly, but it's what the ANSI standard specifies.
It is easy enough for you to make your code work by moving the
definition of @code{struct mumble} above the prototype.  It's not worth
being incompatible with ANSI C just to avoid an error for the example
shown above.

@item
Accesses to bitfields even in volatile objects works by accessing larger
objects, such as a byte or a word.  You cannot rely on what size of
object is accessed in order to read or write the bitfield; it may even
vary for a given bitfield according to the precise usage.

If you care about controlling the amount of memory that is accessed, use
volatile but do not use bitfields.

@item
GNU CC comes with shell scripts to fix certain known problems in system
header files.  They install corrected copies of various header files in
a special directory where only GNU CC will normally look for them.  The
scripts adapt to various systems by searching all the system header
files for the problem cases that we know about.

If new system header files are installed, nothing automatically arranges
to update the corrected header files.  You will have to reinstall GNU CC
to fix the new header files.  More specifically, go to the build
directory and delete the files @file{stmp-fixinc} and
@file{stmp-headers}, and the subdirectory @code{include}; then do
@samp{make install} again.

@item
@cindex floating point precision
On 68000 and x86 systems, for instance, you can get paradoxical results
if you test the precise values of floating point numbers.  For example,
you can find that a floating point value which is not a NaN is not equal
to itself.  This results from the fact that the floating point registers
hold a few more bits of precision than fit in a @code{double} in memory.
Compiled code moves values between memory and floating point registers
at its convenience, and moving them into memory truncates them.

You can partially avoid this problem by using the @samp{-ffloat-store}
option (@pxref{Optimize Options}).

@item
On the MIPS, variable argument functions using @file{varargs.h}
cannot have a floating point value for the first argument.  The
reason for this is that in the absence of a prototype in scope,
if the first argument is a floating point, it is passed in a
floating point register, rather than an integer register.

If the code is rewritten to use the ANSI standard @file{stdarg.h}
method of variable arguments, and the prototype is in scope at
the time of the call, everything will work fine.

@item
On the H8/300 and H8/300H, variable argument functions must be
implemented using the ANSI standard @file{stdarg.h} method of
variable arguments.  Furthermore, calls to functions using @file{stdarg.h}
variable arguments must have a prototype for the called function
in scope at the time of the call.
@end itemize

@node C++ Misunderstandings
@section Common Misunderstandings with GNU C++

@cindex misunderstandings in C++
@cindex surprises in C++
@cindex C++ misunderstandings
C++ is a complex language and an evolving one, and its standard definition
(the ANSI C++ draft standard) is also evolving.  As a result,
your C++ compiler may occasionally surprise you, even when its behavior is
correct.  This section discusses some areas that frequently give rise to
questions of this sort.

@menu
* Static Definitions::  Static member declarations are not definitions
* Temporaries::         Temporaries may vanish before you expect
@end menu

@node Static Definitions
@subsection Declare @emph{and} Define Static Members

@cindex C++ static data, declaring and defining
@cindex static data in C++, declaring and defining
@cindex declaring static data in C++
@cindex defining static data in C++
When a class has static data members, it is not enough to @emph{declare}
the static member; you must also @emph{define} it.  For example:

@example
class Foo
@{
  @dots{}
  void method();
  static int bar;
@};
@end example

This declaration only establishes that the class @code{Foo} has an
@code{int} named @code{Foo::bar}, and a member function named
@code{Foo::method}.  But you still need to define @emph{both}
@code{method} and @code{bar} elsewhere.  According to the draft ANSI
standard, you must supply an initializer in one (and only one) source
file, such as:

@example
int Foo::bar = 0;
@end example

Other C++ compilers may not correctly implement the standard behavior.
As a result, when you switch to @code{g++} from one of these compilers,
you may discover that a program that appeared to work correctly in fact
does not conform to the standard: @code{g++} reports as undefined
symbols any static data members that lack definitions.

@node Temporaries
@subsection Temporaries May Vanish Before You Expect

@cindex temporaries, lifetime of
@cindex portions of temporary objects, pointers to
It is dangerous to use pointers or references to @emph{portions} of a
temporary object.  The compiler may very well delete the object before
you expect it to, leaving a pointer to garbage.  The most common place
where this problem crops up is in classes like the libg++
@code{String} class, that define a conversion function to type
@code{char *} or @code{const char *}.  However, any class that returns
a pointer to some internal structure is potentially subject to this
problem.

For example, a program may use a function @code{strfunc} that returns
@code{String} objects, and another function @code{charfunc} that
operates on pointers to @code{char}:

@example
String strfunc ();
void charfunc (const char *);
@end example

@noindent
In this situation, it may seem natural to write @w{@samp{charfunc
(strfunc ());}} based on the knowledge that class @code{String} has an
explicit conversion to @code{char} pointers.  However, what really
happens is akin to @samp{charfunc (@w{strfunc ()}.@w{convert ()});},
where the @code{convert} method is a function to do the same data
conversion normally performed by a cast.  Since the last use of the
temporary @code{String} object is the call to the conversion function,
the compiler may delete that object before actually calling
@code{charfunc}.  The compiler has no way of knowing that deleting the
@code{String} object will invalidate the pointer.  The pointer then
points to garbage, so that by the time @code{charfunc} is called, it
gets an invalid argument.

Code like this may run successfully under some other compilers,
especially those that delete temporaries relatively late.  However, the
GNU C++ behavior is also standard-conforming, so if your program depends
on late destruction of temporaries it is not portable.

If you think this is surprising, you should be aware that the ANSI C++
committee continues to debate the lifetime-of-temporaries problem.

For now, at least, the safe way to write such code is to give the
temporary a name, which forces it to remain until the end of the s