Red Hat ENTERPRISE LINUX 4 Manual page 305

Chapter 11. Known Causes of Trouble with GCC
(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.)
Undefining
• __STDC__
Currently, GCC defines
Programmers normally use conditionals on
tures of ISO C, such as function prototypes or ISO token concatenation. Since plain
all the features of ISO C, the correct answer to these questions is "yes".
Some users try to use
actually incorrect usage in an ISO C program, because the ISO C standard says that a conforming
freestanding implementation should define
facilities.
gcc -ansi -pedantic
required to define
Sometimes people say that defining
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
. Whatever the ISO C standard says is relevant to the design of plain
gcc
for pragmatic reasons, not as a requirement.
GCC normally defines
the option, or a
-ansi
system include files use a different convention, where
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.
Undefining
• __STDC__
Programs written to compile with C++-to-C translators get the value of
the C compiler that is subsequently used. These programs must test
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
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
is not defined, they will all fail, and will all need to be changed to test explicitly for C++
__STDC__
as well.
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,
which holds for C but is not always the case for C++.
Moreover, with
-funroll-loops
ior is both sub-optimal and inconsistent and will change in the future.
Making side effects happen in the same order as in some other compiler.
•
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:
void func (int, int);
int i = 2;
func (i++, i++);
when is not used.
-ansi
unconditionally. This provides good results in practice.
__STDC__
to check for the availability of certain library facilities. This is
__STDC__
is a conforming freestanding implementation, and it is therefore
, even though it does not come with an ISO C library.
__STDC__
__STDC__
to be 1, and in addition defines
__STDC__
option for strict conformance to some version of ISO C. On some hosts,
-std
in C++.
small "empty" loops are already removed, so the current behav-
to ask whether it is safe to use certain fea-
__STDC__
even though it does not have the library
__STDC__
in a compiler that does not completely conform to
--not for other compilers such as plain
gcc -ansi
__STRICT_ANSI__
__STDC__
is defined. They would not work
__STDC__
gcc
without
gcc
if you specify
is normally 0, but is 1 if the user
that goes with
__STDC__
to determine what
__STDC__
is defined. If
__STDC__
297
supports
only
-ansi