C standard: ANSI C ISO C GUN C {__VA_ARGS__ __FUNCTION__}

选自: gcc-arm-none-eabi/info/gcc.info
点击(此处)折叠或打开

* gcc: (gcc). The GNU Compiler Collection. ---"(GNU Tools for ARM Embedded Processors)"

2.1 C language
==============
 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 "C89", or occasionally as "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 `-ansi', `-std=c90' or `-std=iso9899:1990'; to obtain all the diagnostics required by the standard, you should also specify `-pedantic' (or `-pedantic-errors' if you want them to be errors rather than warnings). *Note Options Controlling C Dialect: C Dialect Options.
 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 `__STDC_VERSION__' to the language, but otherwise concerned the library. This amendment is commonly known as "AMD1"; the amended standard is sometimes known as "C94" or "C95". To select this standard in GCC, use the option `-std=iso9899:199409' (with, as for other standard versions, `-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 "C99". GCC has incomplete support for this standard version; see `http://gcc.gnu.org/c99status.html' for details. To select this standard, use `-std=c99' or `-std=iso9899:1999'. (While in development, drafts of this standard version were referred to as "C9X".)
 Errors in the 1999 ISO C standard were corrected in three Technical Corrigenda published in 2001, 2004 and 2007. GCC does not support the uncorrected version.

 A fourth version of the C standard, known as "C11", was published in 2011 as ISO/IEC 9899:2011. GCC has limited incomplete support for parts of this standard, enabled with `-std=c11' or `-std=iso9899:2011'. (While in development, drafts of this standard version were referred to as "C1X".)


 By default, GCC provides some extensions to the C language that on rare occasions conflict with the C standard. *Note Extensions to the C Language Family: C Extensions. Use of the `-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 `-std=gnu90' (for C90 with GNU extensions), `-std=gnu99' (for C99 with GNU extensions) or `-std=gnu11' (for C11 with GNU extensions). The default, if no C language dialect options are given, is `-std=gnu90'; this will change to `-std=gnu99' or `-std=gnu11' in some future release when the C99 or C11 support is complete. Some features that are part of the C99 standard are accepted as extensions in C90 mode, and some features that are part of the C11 standard are accepted as extensions in C90 and C99 modes.


 GCC 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). *Note Standard Libraries: Standard Libraries.

6 Extensions to the C Language Family
*************************************

GNU C provides several language features not found in ISO standard C.
(The `-pedantic' option directs GCC to print a warning message if any
of these features is used.) To test for the availability of these
features in conditional compilation, check for a predefined macro
`__GNUC__', which is always defined under GCC.

 These extensions are available in C and Objective-C. Most of them are
also available in C++. *Note Extensions to the C++ Language: C++
Extensions, for extensions that apply _only_ to C++.

 Some features that are in ISO C99 but not C90 or C++ are also, as
extensions, accepted by GCC in C90 mode and in C++.


6.20 Macros with a Variable Number of Arguments.
================================================

In the ISO C standard of 1999, a macro can be declared to accept a
variable number of arguments much as a function can. The syntax for
defining the macro is similar to that of a function. Here is an
example:

     #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)

Here `...' is a "variable argument". In the invocation of such a
macro, it represents the zero or more tokens until the closing
parenthesis that ends the invocation, including any commas. This set of
tokens replaces the identifier `__VA_ARGS__' in the macro body wherever
it appears. See the CPP manual for more information.

 GCC has long supported variadic macros, and used a different syntax
that allowed you to give a name to the variable arguments just like any
other argument. Here is an example:

     #define debug(format, args...) fprintf (stderr, format, args)

This is in all ways equivalent to the ISO C example above, but arguably
more readable and descriptive.

 GNU CPP has two further variadic macro extensions, and permits them to
be used with either of the above forms of macro definition.

 In standard C, you are not allowed to leave the variable argument out
entirely; but you are allowed to pass an empty argument. For example,
this invocation is invalid in ISO C, because there is no comma after
the string:

     debug ("A message")

 GNU CPP permits you to completely omit the variable arguments in this
way. In the above examples, the compiler would complain, though since
the expansion of the macro still has the extra comma after the format
string.

 To help solve this problem, CPP behaves specially for variable
arguments used with the token paste operator, `##'. If instead you
write

     #define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)

and if the variable arguments are omitted or empty, the `##' operator
causes the preprocessor to remove the comma before it. If you do
provide some variable arguments in your macro invocation, GNU CPP does
not complain about the paste operation and instead places the variable
arguments after the comma. Just like any other pasted macro argument,
these arguments are not macro expanded.


6.47 Function Names as Strings
==============================

GCC provides three magic variables that hold the name of the current
function, as a string. The first of these is `__func__', which is part
of the C99 standard:

 The identifier `__func__' is implicitly declared by the translator as
if, immediately following the opening brace of each function
definition, the declaration

     static const char __func__[] = "function-name";

appeared, where function-name is the name of the lexically-enclosing
function. This name is the unadorned name of the function.

 `__FUNCTION__' is another name for `__func__'. Older versions of GCC
recognize only this name. However, it is not standardized. For
maximum portability, we recommend you use `__func__', but provide a
fallback definition with the preprocessor:

     #if __STDC_VERSION__ < 199901L
     # if __GNUC__ >= 2
     #  define __func__ __FUNCTION__
     # else
     #  define __func__ ""
     # endif
     #endif

 In C, `__PRETTY_FUNCTION__' is yet another name for `__func__'.
However, in C++, `__PRETTY_FUNCTION__' contains the type signature of
the function as well as its bare name. For example, this program:

     extern "C" {
     extern int printf (char *, ...);
     }

     class a {
      public:
       void sub (int i)
         {
           printf ("__FUNCTION__ = %s\n", __FUNCTION__);
           printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
         }
     };

     int
     main (void)
     {
       a ax;
       ax.sub (0);
       return 0;
     }

gives this output:

     __FUNCTION__ = sub
     __PRETTY_FUNCTION__ = void a::sub(int)

 These identifiers are not preprocessor macros. In GCC 3.3 and
earlier, in C only, `__FUNCTION__' and `__PRETTY_FUNCTION__' were
treated as string literals; they could be used to initialize `char'
arrays, and they could be concatenated with other string literals. GCC
3.4 and later treat them as variables, like `__func__'. In C++,
`__FUNCTION__' and `__PRETTY_FUNCTION__' have always been variables.


6.55 Other Built-in Functions Provided by GCC
=============================================

 -- Built-in Function: int __builtin_FUNCTION ()
     This function is the equivalent to the preprocessor `__FUNCTION__'
     macro and returns the function name the invocation of the built-in
     is in.

另，可参考:
ANSI C与C89、C99、C11区别差异
GNU C 与 ANSI C 的一些差别