trouble.texi

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

@item
@command{protoize} cannot get the argument types for a function whose
definition was not actually compiled due to preprocessing conditionals.
When this happens, @command{protoize} changes nothing in regard to such
a function.  @command{protoize} tries to detect such instances and warn
about them.

You can generally work around this problem by using @command{protoize} step
by step, each time specifying a different set of @option{-D} options for
compilation, until all of the functions have been converted.  There is
no automatic way to verify that you have got them all, however.

@item
Confusion may result if there is an occasion to convert a function
declaration or definition in a region of source code where there is more
than one formal parameter list present.  Thus, attempts to convert code
containing multiple (conditionally compiled) versions of a single
function header (in the same vicinity) may not produce the desired (or
expected) results.

If you plan on converting source files which contain such code, it is
recommended that you first make sure that each conditionally compiled
region of source code which contains an alternative function header also
contains at least one additional follower token (past the final right
parenthesis of the function header).  This should circumvent the
problem.

@item
@command{unprotoize} can become confused when trying to convert a function
definition or declaration which contains a declaration for a
pointer-to-function formal argument which has the same name as the
function being defined or declared.  We recommend you avoid such choices
of formal parameter names.

@item
You might also want to correct some of the indentation by hand and break
long lines.  (The conversion programs don't write lines longer than
eighty characters in any case.)
@end itemize

@node Non-bugs
@section Certain Changes We Don't Want to Make

This section lists changes that people frequently request, but which
we do not make because we think GCC is better without them.

@itemize @bullet
@item
Checking the number and type of arguments to a function which has an
old-fashioned definition and no prototype.

Such a feature would work only occasionally---only for calls that appear
in the same file as the called function, following the definition.  The
only way to check all calls reliably is to add a prototype for the
function.  But adding a prototype eliminates the motivation for this
feature.  So the feature is not worthwhile.

@item
Warning about using an expression whose type is signed as a shift count.

Shift count operands are probably signed more often than unsigned.
Warning about this would cause far more annoyance than good.

@item
Warning about assigning a signed value to an unsigned variable.

Such assignments must be very common; warning about them would cause
more annoyance than good.

@item
Warning when a non-void function value is ignored.

C contains many standard functions that return a value that most
programs choose to ignore.  One obvious example is @code{printf}.
Warning about this practice only leads the defensive programmer to
clutter programs with dozens of casts to @code{void}.  Such casts are
required so frequently that they become visual noise.  Writing those
casts becomes so automatic that they no longer convey useful
information about the intentions of the programmer.  For functions
where the return value should never be ignored, use the
@code{warn_unused_result} function attribute (@pxref{Function
Attributes}).

@item
@opindex fshort-enums
Making @option{-fshort-enums} the default.

This would cause storage layout to be incompatible with most other C
compilers.  And it doesn't seem very important, given that you can get
the same result in other ways.  The case where it matters most is when
the enumeration-valued object is inside a structure, and in that case
you can specify a field width explicitly.

@item
Making bit-fields unsigned by default on particular machines where ``the
ABI standard'' says to do so.

The ISO C standard leaves it up to the implementation whether a bit-field
declared plain @code{int} is signed or not.  This in effect creates two
alternative dialects of C@.

@opindex fsigned-bitfields
@opindex funsigned-bitfields
The GNU C compiler supports both dialects; you can specify the signed
dialect with @option{-fsigned-bitfields} and the unsigned dialect with
@option{-funsigned-bitfields}.  However, this leaves open the question of
which dialect to use by default.

Currently, the preferred dialect makes plain bit-fields signed, because
this is simplest.  Since @code{int} is the same as @code{signed int} in
every other context, it is cleanest for them to be the same in bit-fields
as well.

Some computer manufacturers have published Application Binary Interface
standards which specify that plain bit-fields should be unsigned.  It is
a mistake, however, to say anything about this issue in an ABI@.  This is
because the handling of plain bit-fields distinguishes two dialects of C@.
Both dialects are meaningful on every type of machine.  Whether a
particular object file was compiled using signed bit-fields or unsigned
is of no concern to other object files, even if they access the same
bit-fields in the same data structures.

A given program is written in one or the other of these two dialects.
The program stands a chance to work on most any machine if it is
compiled with the proper dialect.  It is unlikely to work at all if
compiled with the wrong dialect.

Many users appreciate the GNU C compiler because it provides an
environment that is uniform across machines.  These users would be
inconvenienced if the compiler treated plain bit-fields differently on
certain machines.

Occasionally users write programs intended only for a particular machine
type.  On these occasions, the users would benefit if the GNU C compiler
were to support by default the same dialect as the other compilers on
that machine.  But such applications are rare.  And users writing a
program to run on more than one type of machine cannot possibly benefit
from this kind of compatibility.

This is why GCC does and will treat plain bit-fields in the same
fashion on all types of machines (by default).

There are some arguments for making bit-fields unsigned by default on all
machines.  If, for example, this becomes a universal de facto standard,
it would make sense for GCC to go along with it.  This is something
to be considered in the future.

(Of course, users strongly concerned about portability should indicate
explicitly in each bit-field whether it is signed or not.  In this way,
they write programs which have the same meaning in both C dialects.)

@item
@opindex ansi
@opindex std
Undefining @code{__STDC__} when @option{-ansi} is not used.

Currently, GCC defines @code{__STDC__} unconditionally.  This provides
good results in practice.

Programmers normally use conditionals on @code{__STDC__} to ask whether
it is safe to use certain features of ISO C, such as function
prototypes or ISO token concatenation.  Since plain @command{gcc} supports
all the features of ISO C, the correct answer to these questions is
``yes''.

Some users try to use @code{__STDC__} to check for the availability of
certain library facilities.  This is actually incorrect usage in an ISO
C program, because the ISO C standard says that a conforming
freestanding implementation should define @code{__STDC__} even though it
does not have the library facilities.  @samp{gcc -ansi -pedantic} is a
conforming freestanding implementation, and it is therefore required to
define @code{__STDC__}, even though it does not come with an ISO C
library.

Sometimes people say that defining @code{__STDC__} in a compiler that
does not completely conform to the ISO C standard somehow violates the
standard.  This is illogical.  The standard is a standard for compilers
that claim to support ISO C, such as @samp{gcc -ansi}---not for other
compilers such as plain @command{gcc}.  Whatever the ISO C standard says
is relevant to the design of plain @command{gcc} without @option{-ansi} only
for pragmatic reasons, not as a requirement.

GCC normally defines @code{__STDC__} to be 1, and in addition
defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option,
or a @option{-std} option for strict conformance to some version of ISO C@.
On some hosts, system include files use a different convention, where
@code{__STDC__} is normally 0, but is 1 if the user specifies strict
conformance to the C Standard.  GCC follows the host convention when
processing system include files, but when processing user files it follows
the usual GNU C convention.

@item
Undefining @code{__STDC__} in C++.

Programs written to compile with C++-to-C translators get the
value of @code{__STDC__} that goes with the C compiler that is
subsequently used.  These programs must test @code{__STDC__}
to determine what kind of C preprocessor that compiler uses:
whether they should concatenate tokens in the ISO C fashion
or in the traditional fashion.

These programs work properly with GNU C++ if @code{__STDC__} is defined.
They would not work otherwise.

In addition, many header files are written to provide prototypes in ISO
C but not in traditional C@.  Many of these header files can work without
change in C++ provided @code{__STDC__} is defined.  If @code{__STDC__}
is not defined, they will all fail, and will all need to be changed to
test explicitly for C++ as well.

@item
Deleting ``empty'' loops.

Historically, GCC has not deleted ``empty'' loops under the
assumption that the most likely reason you would put one in a program is
to have a delay, so deleting them will not make real programs run any
faster.

However, the rationale here is that optimization of a nonempty loop
cannot produce an empty one. This held for carefully written C compiled
with less powerful optimizers but is not always the case for carefully
written C++ or with more powerful optimizers.
Thus GCC will remove operations from loops whenever it can determine
those operations are not externally visible (apart from the time taken
to execute them, of course).  In case the loop can be proved to be finite,
GCC will also remove the loop itself.

Be aware of this when performing timing tests, for instance the
following loop can be completely removed, provided
@code{some_expression} can provably not change any global state.

@smallexample
@{
   int sum = 0;
   int ix;

   for (ix = 0; ix != 10000; ix++)
      sum += some_expression;
@}
@end smallexample

Even though @code{sum} is accumulated in the loop, no use is made of
that summation, so the accumulation can be removed.

@item
Making side effects happen in the same order as in some other compiler.

@cindex side effects, order of evaluation
@cindex order of evaluation, side effects
It is never safe to depend on the order of evaluation of side effects.
For example, a function call like this may very well behave differently
from one compiler to another:

@smallexample
void func (int, int);

int i = 2;
func (i++, i++);
@end smallexample

There is no guarantee (in either the C or the C++ standard language
definitions) that the increments will be evaluated in any particular
order.  Either increment might happen first.  @code{func} might get the
arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.

@item
Making certain warnings into errors by default.

Some ISO C testsuites report failure when the compiler does not produce
an error message for a certain program.

@opindex pedantic-errors
ISO C requires a ``diagnostic'' message for certain kinds of invalid
programs, but a warning is defined by GCC to count as a diagnostic.  If
GCC produces a warning but not an error, that is correct ISO C support.
If testsuites call this ``failure'', they should be run with the GCC
option @option{-pedantic-errors}, which will turn these warnings into
errors.

@end itemize

@node Warnings and Errors
@section Warning Messages and Error Messages

@cindex error messages
@cindex warnings vs errors
@cindex messages, warning and error
The GNU compiler can produce two kinds of diagnostics: errors and
warnings.  Each kind has a different purpose:

@itemize @w{}
@item
@dfn{Errors} report problems that make it impossible to compile your
program.  GCC reports errors with the source file name and line
number where the problem is apparent.

@item
@dfn{Warnings} report other unusual conditions in your code that
@emph{may} indicate a problem, although compilation can (and does)
proceed.  Warning messages also report the source file name and line
number, but include the text @samp{warning:} to distinguish them
from error messages.
@end itemize

Warnings may indicate danger points where you should check to make sure
that your program really does what you intend; or the use of obsolete
features; or the use of nonstandard features of GNU C or C++.  Many
warnings are issued only if you ask for them, with one of the @option{-W}
options (for instance, @option{-Wall} requests a variety of useful
warnings).

@opindex pedantic
@opindex pedantic-errors
GCC always tries to compile your program if possible; it never
gratuitously rejects a program whose meaning is clear merely because
(for instance) it fails to conform to a standard.  In some cases,
however, the C and C++ standards specify that certain extensions are
forbidden, and a diagnostic @emph{must} be issued by a conforming
compiler.  The @option{-pedantic} option tells GCC to issue warnings in
such cases; @option{-pedantic-errors} says to make them errors instead.
This does not mean that @emph{all} non-ISO constructs get warnings
or errors.

@xref{Warning Options,,Options to Request or Suppress Warnings}, for
more detail on these and related command-line options.