OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

gcc.texi, [...]: Add new section discussing language standards... 

* gcc.texi, invoke.texi: Add new section discussing language
	standards; link to it where appropriate; refer to ISO C instead of
	ANSI C.

From-SVN: r37383
This commit is contained in:
Joseph Myers 2000-11-11 10:06:22 +00:00 committed by Joseph Myers
parent 0babc59ad8
commit c1030c7c86
3 changed files with 241 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gcc/ChangeLog
View File

@ -1,3 +1,9 @@
2000-11-11 Joseph S. Myers <jsm28@cam.ac.uk>
* gcc.texi, invoke.texi: Add new section discussing language
standards; link to it where appropriate; refer to ISO C instead of
ANSI C.
2000-11-11 Alexandre Oliva <aoliva@redhat.com>
* builtins.c (std_expand_builtin_va_start): Take PARM_BOUNDARY

245
gcc/gcc.texi
View File

@ -210,6 +210,7 @@ bugs. It corresponds to GCC version 2.97.
@menu
@ifset USING
* G++ and GCC:: You can compile C or C++ programs.
* Standards:: Language standards supported by GCC.
* Invoking GCC:: Command options supported by @samp{gcc}.
* Installation:: How to configure, compile and install GCC.
* C Extensions:: GNU extensions to the C language family.
@ -300,6 +301,157 @@ give you comprehensive C++ source-level editing capabilities
@c a paragraph or two about it here, and move the index entry down when
@c there is more to point to than the general mention in the 1st par.
@node Standards
@chapter Language Standards Supported by GCC
@cindex C standard
@cindex C standards
@cindex ANSI C standard
@cindex ANSI C
@cindex ANSI C89
@cindex C89
@cindex ANSI X3.159-1989
@cindex X3.159-1989
@cindex ISO C standard
@cindex ISO C
@cindex ISO C89
@cindex ISO C90
@cindex ISO/IEC 9899
@cindex ISO 9899
@cindex C90
@cindex ISO C94
@cindex C94
@cindex ISO C95
@cindex C95
@cindex ISO C99
@cindex C99
@cindex ISO C9X
@cindex C9X
@cindex Technical Corrigenda
@cindex TC1
@cindex Technical Corrigendum 1
@cindex TC2
@cindex Technical Corrigendum 2
@cindex AMD1
@cindex freestanding implementation
@cindex freestanding environment
@cindex hosted implementation
@cindex hosted environment
@findex __STDC_HOSTED__
For each language compiled by GCC for which there is a standard, GCC
attempts to follow one or more versions of that standard, possibly
with some limitations.
GCC supports three versions of the C standard, although support for
the most recent version is not yet complete.
The original ANSI C standard (X3.159-1989) was ratified in 1989 and
published in 1990. This standard was ratified as an ISO standard
(ISO/IEC 9899:1990) later in 1990. There were no technical
differences between these publications, although the sections of the
ANSI standard were renumbered and became clauses in the ISO standard.
This standard, in both its forms, is commonly known as @dfn{C89}, or
occasionally as @dfn{C90}, from the dates of ratification. The ANSI
standard, but not the ISO standard, also came with a Rationale
document. To select this standard in GCC, use one of the options
@samp{-ansi}, @samp{-std=c89} or @samp{-std=iso9899:1990}; to obtain
all the diagnostics required by the standard, you should also specify
@samp{-pedantic} (or @samp{-pedantic-errors} if you want them to be
errors rather than warnings). @xref{C Dialect Options,,Options
Controlling C Dialect}.
Errors in the 1990 ISO C standard were corrected in two Technical
Corrigenda published in 1994 and 1996. GCC does not support the
uncorrected version.
An amendment to the 1990 standard was published in 1995. This
amendment added digraphs and @code{__STDC_VERSION__} to the language,
but otherwise concerned the library. This amendment is commonly known
as @dfn{AMD1}; the amended standard is sometimes known as @dfn{C94} or
@dfn{C95}. To select this standard in GCC, use the option
@samp{-std=iso9899:199409} (with, as for other standard versions,
@samp{-pedantic} to receive all required diagnostics).
A new edition of the ISO C standard was published in 1999 as ISO/IEC
9899:1999, and is commonly known as @dfn{C99}. GCC has incomplete
support for this standard version; see
@uref{http://gcc.gnu.org/c99status.html} for details. To select this
standard, use @samp{-std=c99} or @samp{-std=iso9899:1999}. (While in
development, drafts of this standard version were referred to as
@dfn{C9X}.)
GCC also has some limited support for traditional (pre-ISO) C with the
@samp{-traditional} option. This support may be of use for compiling
some very old programs that have not been updated to ISO C, but should
not be used for new programs. It will not work with some modern C
libraries such as the GNU C library.
By default, GCC provides some extensions to the C language that on
rare occasions conflict with the C standard. @xref{C
Extensions,,Extensions to the C Language Family}. Use of the
@samp{-std} options listed above will disable these extensions where
they conflict with the C standard version selected. You may also
select an extended version of the C language explicitly with
@samp{-std=gnu89} (for C89 with GNU extensions) or @samp{-std=gnu99}
(for C99 with GNU extensions). The default, if no C language dialect
options are given, is @samp{-std=gnu89}; this will change to
@samp{-std=gnu99} in some future release when the C99 support is
complete. Some features that are part of the C99 standard are
accepted as extensions in C89 mode.
The ISO C standard defines (in clause 4) two classes of conforming
implementation. A @dfn{conforming hosted implementation} supports the
whole standard including all the library facilities; a @dfn{conforming
freestanding implementation} is only required to provide certain
library facilities: those in @code{<float.h>}, @code{<limits.h>},
@code{<stdarg.h>}, and @code{<stddef.h>}; since AMD1, also those in
@code{<iso646.h>}; and in C99, also those in @code{<stdbool.h>} and
@code{<stdint.h>}. In addition, complex types, added in C99, are not
required for freestanding implementations. The standard also defines
two environments for programs, a @dfn{freestanding environment},
required of all implementations and which may not have library
facilities beyond those required of freestanding implementations,
where the handling of program startup and termination are
implementation-defined, and a @dfn{hosted environment}, which is not
required, in which all the library facilities are provided and startup
is through a function @code{int main (void)} or @code{int main (int,
char *[])}. An OS kernel would be a freestanding environment; a
program using the facilities of an operating system would normally be
in a hosted implementation.
GNU CC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation. By default, it will act as the compiler for a hosted
implementation, defining @code{__STDC_HOSTED__} as @code{1} and
presuming that when the names of ISO C functions are used, they have
the semantics defined in the standard. To make it act as a conforming
freestanding implementation for a freestanding environment, use the
option @samp{-ffreestanding}; it will then define
@code{__STDC_HOSTED__} to @code{0} and not make assumptions about the
meanings of function names from the standard library. To build an OS
kernel, you may well still need to make your own arrangements for
linking and startup. @xref{C Dialect Options,,Options Controlling C
Dialect}.
GNU CC does not provide the library facilities required only of hosted
implementations, nor yet all the facilities required by C99 of
freestanding implementations; to use the facilities of a hosted
environment, you will need to find them elsewhere (for example, in the
GNU C library). @xref{Standard Libraries,,Standard Libraries}.
For references to Technical Corrigenda, Rationale documents and
information concerning the history of C that is available online, see
@uref{http://gcc.gnu.org/readings.html}
@c FIXME: details of C++ standard.
@c FIXME: definitions of Java and Objective C.
@xref{Language,,The GNU Fortran Language, g77, Using and Porting GNU
Fortran}, for details of the Fortran language supported by GCC.
@xref{References,,Language Definition References, chill, GNU Chill},
for details of the CHILL standard.
@include invoke.texi
@include install.texi
@ -333,7 +485,7 @@ where people's opinions differ as to what is best.
* Fixed Headers:: GNU C uses corrected versions of system header files.
This is necessary, but doesn't always work smoothly.
* Standard Libraries:: GNU C uses the system C library, which might not be
compliant with the ISO/ANSI C standard.
compliant with the ISO C standard.
* Disappointments:: Regrettable things we can't change, but not quite bugs.
* C++ Misunderstandings:: Common misunderstandings with GNU C++.
* Protoize Caveats:: Things to watch out for when using @code{protoize}.
@ -1039,7 +1191,7 @@ static int foo;
will cause the linker to report an undefined symbol @code{foo}.
Although this behavior differs from most other systems, it is not a
bug because redefining an @code{extern} variable as @code{static}
is undefined in ANSI C.
is undefined in ISO C.
@item
AIX on the RS/6000 provides support (NLS) for environments outside of
@ -1165,7 +1317,7 @@ Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2
because of problems in DEC's versions of the X11 header files
@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding
@samp{-I/usr/include/mit} to use the MIT versions of the header files,
using the @samp{-traditional} switch to turn off ANSI C, or fixing the
using the @samp{-traditional} switch to turn off ISO C, or fixing the
header files by adding this:
@example
@ -1205,7 +1357,7 @@ MALLOC=gmalloc.o
@cindex incompatibilities of GCC
There are several noteworthy incompatibilities between GNU C and K&R
(non-ANSI) versions of C. The @samp{-traditional} option
(non-ISO) versions of C. The @samp{-traditional} option
eliminates many of these incompatibilities, @emph{but not all}, by
telling GNU C to behave like a K&R C compiler.
@ -1242,7 +1394,7 @@ to handle string constants the same way most C compilers do.
@code{-2147483648} is positive.
This is because 2147483648 cannot fit in the type @code{int}, so
(following the ANSI C rules) its data type is @code{unsigned long int}.
(following the ISO C rules) its data type is @code{unsigned long int}.
Negating this value yields 2147483648 again.
@item
@ -1257,7 +1409,7 @@ string constants. For example, the following macro in GCC
will produce output @code{"a"} regardless of what the argument @var{a} is.
The @samp{-traditional} option directs GCC to handle such cases
(among others) in the old-fashioned (non-ANSI) fashion.
(among others) in the old-fashioned (non-ISO) fashion.
@cindex @code{setjmp} incompatibilities
@cindex @code{longjmp} incompatibilities
@ -1308,7 +1460,7 @@ foobar (
hack)
@end example
ANSI C does not permit such a construct. It would make sense to support
ISO C does not permit such a construct. It would make sense to support
it when @samp{-traditional} is used, but it is too much work to
implement.
@ -1340,7 +1492,7 @@ typedef int foo;
typedef long foo bar;
@end example
In ANSI C, this is not allowed: @code{long} and other type modifiers
In ISO C, this is not allowed: @code{long} and other type modifiers
require an explicit @code{int}. Because this criterion is expressed
by Bison grammar rules rather than C code, the @samp{-traditional}
flag cannot alter it.
@ -1370,7 +1522,7 @@ 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 ANSI standard, does not
such as @samp{+=}. GCC, following the ISO standard, does not
allow this. The difficulty described immediately above applies here
too.
@ -1397,7 +1549,7 @@ C comment delimited by @samp{/*@dots{}*/}. However,
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. 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.
@ -1451,7 +1603,7 @@ 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
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
@ -1469,7 +1621,7 @@ the minus sign. This whitespace will end the preprocessing number.
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 ANSI C, and some depend on special features of other
incompatible with ISO C, and some depend on special features of other
compilers.
Installing GCC automatically creates and installs the fixed header
@ -1516,14 +1668,13 @@ does mean that there's nothing for us to do about them.
@node Standard Libraries
@section Standard Libraries
GCC 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.
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
@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
@ -1533,9 +1684,11 @@ 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})
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.
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
@ -1582,10 +1735,10 @@ 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.
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 ANSI C just to avoid an error for the example
being incompatible with ISO C just to avoid an error for the example
shown above.
@item
@ -1631,13 +1784,13 @@ 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}
If the code is rewritten to use the ISO 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
implemented using the ISO 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.
@ -1829,7 +1982,7 @@ For example, it can't determine argument types for declaring a
pointer-to-function variable; this you must do by hand. @code{protoize}
inserts a comment containing @samp{???} each time it finds such a
variable; so you can find all such variables by searching for this
string. ANSI C does not require declaring the argument types of
string. ISO C does not require declaring the argument types of
pointer-to-function types.
@item
@ -1951,7 +2104,7 @@ you can specify a field width explicitly.
Making bitfields unsigned by default on particular machines where ``the
ABI standard'' says to do so.
The ANSI C standard leaves it up to the implementation whether a bitfield
The ISO C standard leaves it up to the implementation whether a bitfield
declared plain @code{int} is signed or not. This in effect creates two
alternative dialects of C.
@ -2010,25 +2163,25 @@ Currently, GCC defines @code{__STDC__} as long as you don't use
@samp{-traditional}. This provides good results in practice.
Programmers normally use conditionals on @code{__STDC__} to ask whether
it is safe to use certain features of ANSI C, such as function
prototypes or ANSI token concatenation. Since plain @samp{gcc} supports
all the features of ANSI C, the correct answer to these questions is
it is safe to use certain features of ISO C, such as function
prototypes or ISO token concatenation. Since plain @samp{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 ANSI
C program, because the ANSI C standard says that a conforming
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 ANSI C
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 ANSI C standard somehow violates the
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 ANSI C, such as @samp{gcc -ansi}---not for other
compilers such as plain @samp{gcc}. Whatever the ANSI C standard says
that claim to support ISO C, such as @samp{gcc -ansi}---not for other
compilers such as plain @samp{gcc}. Whatever the ISO C standard says
is relevant to the design of plain @samp{gcc} without @samp{-ansi} only
for pragmatic reasons, not as a requirement.
@ -2047,13 +2200,13 @@ 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 ANSI C fashion
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 ANSI
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
@ -2099,7 +2252,7 @@ arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.
@item
Not allowing structures with volatile fields in registers.
Strictly speaking, there is no prohibition in the ANSI C standard
Strictly speaking, there is no prohibition in the ISO C standard
against allowing structures with volatile fields in registers, but
it does not seem to make any sense and is probably not what you wanted
to do. So the compiler will give an error message in this case.
@ -2156,7 +2309,7 @@ however, the C and C++ standards specify that certain extensions are
forbidden, and a diagnostic @emph{must} be issued by a conforming
compiler. The @samp{-pedantic} option tells GCC to issue warnings in
such cases; @samp{-pedantic-errors} says to make them errors instead.
This does not mean that @emph{all} non-ANSI constructs get warnings
This does not mean that @emph{all} non-ISO constructs get warnings
or errors.
@xref{Warning Options,,Options to Request or Suppress Warnings}, for
@ -2913,7 +3066,7 @@ Include directives of the form:
@noindent
are a common source of incompatibility between VAX-C and GCC. VAX-C
treats this much like a standard @code{#include <foobar.h>} directive.
That is incompatible with the ANSI C behavior implemented by GCC: to
That is incompatible with the ISO C behavior implemented by GCC: to
expand the name @code{foobar} as a macro. Macro expansion should
eventually yield one of the two standard formats for @code{#include}:
@ -3054,7 +3207,7 @@ The array ``address'' may not be the address of actual storage.
The fact that the symbol is an array may lead to warnings where the
variable is used. Insert type casts to avoid the warnings. Here is an
example; it takes advantage of the ANSI C feature allowing macros that
example; it takes advantage of the ISO C feature allowing macros that
expand to use the same name as the macro itself.
@example
@ -3269,7 +3422,7 @@ stored in memory, and the address of the memory location is passed to
the subroutine.
@cindex @code{longjmp} and automatic variables
If you use @code{longjmp}, beware of automatic variables. ANSI C says that
If you use @code{longjmp}, beware of automatic variables. ISO C says that
automatic variables that are not declared @code{volatile} have undefined
values after a @code{longjmp}. And this is all GCC promises to do,
because it is very difficult to restore register variables correctly, and
@ -3934,7 +4087,7 @@ used in an expression.
@findex MULTIBYTE_CHARS
@item MULTIBYTE_CHARS
Define this macro to enable support for multibyte characters in the
input to GCC. This requires that the host system support the ANSI C
input to GCC. This requires that the host system support the ISO C
library functions for converting multibyte characters to wide
characters.

66
gcc/invoke.texi
View File

@ -695,36 +695,36 @@ from C, such as C++ and Objective C) that the compiler accepts:
@table @code
@cindex ANSI support
@cindex ISO support
@item -ansi
In C mode, support all ANSI standard C programs. In C++ mode,
In C mode, support all ISO C89 programs. In C++ mode,
remove GNU extensions that conflict with ISO C++.
@c shouldn't we be saying "ISO"?
This turns off certain features of GCC that are incompatible with ANSI
This turns off certain features of GCC that are incompatible with ISO
C (when compiling C code), or of standard C++ (when compiling C++ code),
such as the @code{asm} and @code{typeof} keywords, and
predefined macros such as @code{unix} and @code{vax} that identify the
type of system you are using. It also enables the undesirable and
rarely used ANSI trigraph feature. For the C compiler,
rarely used ISO trigraph feature. For the C compiler,
it disables recognition of C++ style @samp{//} comments as well as
the @code{inline} keyword.
The alternate keywords @code{__asm__}, @code{__extension__},
@code{__inline__} and @code{__typeof__} continue to work despite
@samp{-ansi}. You would not want to use them in an ANSI C program, of
@samp{-ansi}. You would not want to use them in an ISO C program, of
course, but it is useful to put them in header files that might be included
in compilations done with @samp{-ansi}. Alternate predefined macros
such as @code{__unix__} and @code{__vax__} are also available, with or
without @samp{-ansi}.
The @samp{-ansi} option does not cause non-ANSI programs to be
The @samp{-ansi} option does not cause non-ISO programs to be
rejected gratuitously. For that, @samp{-pedantic} is required in
addition to @samp{-ansi}. @xref{Warning Options}.
The macro @code{__STRICT_ANSI__} is predefined when the @samp{-ansi}
option is used. Some header files may notice this macro and refrain
from declaring certain functions or defining certain macros that the
ANSI standard doesn't call for; this is to avoid interfering with any
ISO standard doesn't call for; this is to avoid interfering with any
programs that might use these names for other things.
Functions which would normally be builtin but do not have semantics
@ -776,6 +776,9 @@ features of newer standards in so far as they do not conflict with
previous C standards. For example, you may use @code{__restrict__} even
when -std=c99 is not specified.
@xref{Standards,,Language Standards Supported by GCC}, for details of
these standard versions.
@item -fno-asm
Do not recognize @code{asm}, @code{inline} or @code{typeof} as a
keyword, so that code can use these words as identifiers. You can use
@ -820,8 +823,11 @@ is one in which the standard library may not exist, and program startup may
not necessarily be at @code{main}. The most obvious example is an OS kernel.
This is equivalent to @samp{-fno-hosted}.
@xref{Standards,,Language Standards Supported by GCC}, for details of
freestanding and hosted environments.
@item -trigraphs
Support ANSI C trigraphs. You don't want to know about this
Support ISO C trigraphs. You don't want to know about this
brain-damage. The @samp{-ansi} option implies @samp{-trigraphs}.
@cindex traditional C language
@ -853,7 +859,7 @@ to @code{unsigned int}.
Out-of-range floating point literals are not an error.
@item
Certain constructs which ANSI regards as a single invalid preprocessing
Certain constructs which ISO regards as a single invalid preprocessing
number, such as @samp{0xe-0xd}, are treated as expressions instead.
@item
@ -865,7 +871,7 @@ separately. (This is the same as the effect of
@cindex @code{longjmp} and automatic variables
@item
All automatic variables not declared @code{register} are preserved by
@code{longjmp}. Ordinarily, GNU C follows ANSI C: automatic variables
@code{longjmp}. Ordinarily, GNU C follows ISO C: automatic variables
not declared @code{volatile} may be clobbered.
@item
@ -883,8 +889,8 @@ if your program uses names that are normally GNU C builtin functions for
other purposes of its own.
You cannot use @samp{-traditional} if you include any header files that
rely on ANSI C features. Some vendors are starting to ship systems with
ANSI C header files and you cannot use @samp{-traditional} on such
rely on ISO C features. Some vendors are starting to ship systems with
ISO C header files and you cannot use @samp{-traditional} on such
systems to compile files that include any system headers.
The @samp{-traditional} option also enables @samp{-traditional-cpp},
@ -917,7 +923,7 @@ which @code{__GNUC__} indicates are not affected by
@samp{-traditional}). If you need to write header files that work
differently depending on whether @samp{-traditional} is in use, by
testing both of these predefined macros you can distinguish four
situations: GNU C, traditional GNU C, other ANSI C compilers, and other
situations: GNU C, traditional GNU C, other ISO C compilers, and other
old C compilers. The predefined macro @code{__STDC_VERSION__} is also
not defined when you use @samp{-traditional}. @xref{Standard
Predefined,,Standard Predefined Macros,cpp.info,The C Preprocessor},
@ -965,8 +971,8 @@ if your program uses names that are normally GNU C builtin functions for
other purposes of its own.
You cannot use @samp{-traditional} if you include any header files that
rely on ANSI C features. Some vendors are starting to ship systems with
ANSI C header files and you cannot use @samp{-traditional} on such
rely on ISO C features. Some vendors are starting to ship systems with
ISO C header files and you cannot use @samp{-traditional} on such
systems to compile files that include any system headers.
@item -fsigned-bitfields
@ -1000,7 +1006,7 @@ architecture for which you are compiling, single precision may be faster
than double precision. If you must use @samp{-traditional}, but want
to use single precision operations when the operands are single
precision, use this option. This option has no effect when compiling
with ANSI or GNU C conventions (the default).
with ISO or GNU C conventions (the default).
@item -fshort-wchar
Override the underlying type for @samp{wchar_t} to be @samp{short
@ -1062,7 +1068,7 @@ Accept @samp{$} in identifiers. You can also explicitly prohibit use of
@samp{$} with the option @samp{-fno-dollars-in-identifiers}. (GNU C allows
@samp{$} by default on most target systems, but there are a few exceptions.)
Traditional C allowed the character @samp{$} to form part of
identifiers. However, ANSI C and C++ forbid @samp{$} in identifiers.
identifiers. However, ISO C and C++ forbid @samp{$} in identifiers.
@item -fno-elide-constructors
The C++ standard allows an implementation to omit creating a temporary
@ -1438,7 +1444,7 @@ these escape routes; application programs should avoid them.
Some users try to use @samp{-pedantic} to check programs for strict ISO
C conformance. They soon find that it does not do quite what they want:
it finds some non-ANSI practices, but not all---only those for which
it finds some non-ISO practices, but not all---only those for which
ISO C @emph{requires} a diagnostic, and some others for which
diagnostics have been added.
@ -1841,13 +1847,13 @@ probably mistaken.
@item -Wtraditional (C only)
Warn about certain constructs that behave differently in traditional and
ANSI C.
ISO C.
@itemize @bullet
@item
Macro arguments occurring within string constants in the macro body.
These would substitute the argument in traditional C, but are part of
the constant in ANSI C.
the constant in ISO C.
@item
A function declared external in one block and then used after the end of
@ -1861,13 +1867,13 @@ A non-@code{static} function declaration follows a @code{static} one.
This construct is not accepted by some traditional C compilers.
@item
The ANSI type of an integer constant has a different width or
The ISO type of an integer constant has a different width or
signedness from its traditional type. This warning is only issued if
the base of the constant is ten. I.e. hexadecimal or octal values, which
typically represent bit patterns, are not warned about.
@item
Usage of ANSI string concatenation is detected.
Usage of ISO string concatenation is detected.
@item
A function macro appears without arguments.
@ -2703,7 +2709,7 @@ that alter the assembler output may be confused by the optimizations
performed when this option is not used.
@item -ffast-math
This option allows GCC to violate some ANSI or IEEE rules and/or
This option allows GCC to violate some ISO or IEEE rules and/or
specifications in the interest of optimizing code for speed. For
example, it allows the compiler to assume arguments to the @code{sqrt}
function are non-negative numbers and that no floating-point values
@ -2711,7 +2717,7 @@ are NaNs.
This option should never be turned on by any @samp{-O} option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ANSI rules/specifications for
an exact implementation of IEEE or ISO rules/specifications for
math functions.
@item -fno-math-errno
@ -3179,7 +3185,7 @@ Like @samp{-dD} except that the macro arguments and contents are omitted.
Only @samp{#define @var{name}} is included in the output.
@item -trigraphs
Support ANSI C trigraphs. The @samp{-ansi} option also has this effect.
Support ISO C trigraphs. The @samp{-ansi} option also has this effect.
@item -Wp,@var{option}
Pass @var{option} as an option to the preprocessor. If @var{option}
@ -3263,7 +3269,7 @@ Do not use the standard system libraries when linking.
Only the libraries you specify will be passed to the linker.
The standard startup files are used normally, unless @code{-nostartfiles}
is used. The compiler may generate calls to memcmp, memset, and memcpy
for System V (and ANSI C) environments or to bcopy and bzero for
for System V (and ISO C) environments or to bcopy and bzero for
BSD environments. These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified.
@ -3272,7 +3278,7 @@ mechanism when this option is specified.
Do not use the standard system startup files or libraries when linking.
No startup files and only the libraries you specify will be passed to
the linker. The compiler may generate calls to memcmp, memset, and memcpy
for System V (and ANSI C) environments or to bcopy and bzero for
for System V (and ISO C) environments or to bcopy and bzero for
BSD environments. These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified.
@ -3655,7 +3661,7 @@ current target machine. Use this when running @code{cpp}.
@item %P
Like @samp{%p}, but puts @samp{__} before and after the name of each
predefined macro, except for macros that start with @samp{__} or with
@samp{_@var{L}}, where @var{L} is an uppercase letter. This is for ANSI
@samp{_@var{L}}, where @var{L} is an uppercase letter. This is for ISO
C.
@item %I
@ -7870,7 +7876,7 @@ recognize and translate multibyte characters.
@section Running Protoize
The program @code{protoize} is an optional part of GNU C. You can use
it to add prototypes to a program, thus converting the program to ANSI
it to add prototypes to a program, thus converting the program to ISO
C in one respect. The companion program @code{unprotoize} does the
reverse: it removes argument types from any prototypes that are found.
@ -7905,7 +7911,7 @@ are called.
Basic conversion with @code{unprotoize} consists of rewriting most
function declarations to remove any argument types, and rewriting
function definitions to the old-style pre-ANSI form.
function definitions to the old-style pre-ISO form.
Both conversion programs print a warning for any function declaration or
definition that they can't convert. You can suppress these warnings