trouble.texi

理解和实践操作系统的一本好书

@smallexample
@group
foobar (
#define luser
        hack)
@end group
@end smallexample

ISO C does not permit such a construct.

@item
K&R compilers allow comments to cross over an inclusion boundary
(i.e.@: started in an include file and ended in the including file).

@cindex external declaration scope
@cindex scope of external declarations
@cindex declaration scope
@item
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.

In some other C compilers, a @code{extern} declaration affects all the
rest of the file even if it happens within a block.

@item
In traditional C, you can combine @code{long}, etc., with a typedef name,
as shown here:

@smallexample
typedef int foo;
typedef long foo bar;
@end smallexample

In ISO C, this is not allowed: @code{long} and other type modifiers
require an explicit @code{int}.

@cindex typedef names as function parameters
@item
PCC allows typedef names to be used as function parameters.

@item
Traditional C allows the following erroneous pair of declarations to
appear together in a given scope:

@smallexample
typedef int foo;
typedef foo foo;
@end smallexample

@item
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.

@cindex whitespace
@item
PCC allows whitespace in the middle of compound assignment operators
such as @samp{+=}.  GCC, following the ISO standard, does not
allow this.

@cindex apostrophes
@cindex '
@item
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:

@smallexample
#if 0
You can't expect this to work.
#endif
@end smallexample

The best solution to such a problem is to put the text into an actual
C comment delimited by @samp{/*@dots{}*/}.

@item
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 ISO 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 appropriate system headers
(@code{<time.h>} on systems with ISO C headers) and not to declare
@code{time} if the system header files declare it, or failing that 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.  GCC 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, 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.

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}
tells GCC 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.  GCC 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.  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.

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

@cindex preprocessing tokens
@cindex preprocessing numbers
@item
GCC 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,
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.

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+}, @samp{E-}, @samp{p+},
@samp{p-}, @samp{P+}, or @samp{P-} character sequences.  (In strict C89
mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot
appear in preprocessing numbers.)

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

GCC 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 GCC unless they are changed.  Some have bugs, some are
incompatible with ISO C, and some depend on special features of other
compilers.

Installing GCC automatically creates and installs the fixed header
files, by running a program called @code{fixincludes}.  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 GCC are not automatically
updated.  They can be updated using the @command{mkheaders} script
installed in
@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.

@item
On some systems, 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 the system 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.

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.
@end itemize

@node Standard Libraries
@section Standard Libraries

@opindex Wall
GCC by itself attempts to be a conforming freestanding implementation.
@xref{Standards,,Language Standards Supported by GCC}, for details of
what this means.  Beyond the library facilities required of such an
implementation, 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
@option{-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
GCC does not provide one.  The GNU C library (called @code{glibc})
provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for
GNU/Linux and HURD-based GNU systems; no recent version of it supports
other systems, though some very old versions did.  Version 2.2 of the
GNU C library includes nearly complete C99 support.  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 GCC 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 GCC 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 GCC reports an error for code
like this:

@smallexample
int foo (struct mumble *);

struct mumble @{ @dots{} @};

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

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 ISO 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 ISO C just to avoid an error for the example
shown above.

@item
Accesses to bit-fields 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 bit-field; it may even
vary for a given bit-field according to the precise usage.

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

@item
GCC 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 GCC 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.  They can be updated using the
@command{mkheaders} script installed in
@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.

@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.

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

@item
On AIX and other platforms without weak symbol support, templates
need to be instantiated explicitly and symbols for static members
of templates will not be generated.

@item
On AIX, GCC scans object files and library archives for static
constructors and destructors when linking an application before the
linker prunes unreferenced symbols.  This is necessary to prevent the
AIX linker from mistakenly assuming that static constructor or
destructor are unused and removing them before the scanning can occur.
All static constructors and destructors found will be referenced even
though the modules in which they occur may not be used by the program.
This may lead to both increased executable size and unexpected symbol
references.
@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