Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1715356
  • 博文数量: 143
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1462
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-23 11:14












2020-09-17 19:18:01

选自: gcc-arm-none-eabi/info/
  1. * gcc: (gcc). The GNU Compiler Collection. ---"(GNU Tools for ARM Embedded Processors)"

  2. 2.1 C language
  3. ==============
  4.  GCC supports three versions of the C standard, although support for the most recent version is not yet complete.

  5.  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.
  6.  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.

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

  8.  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 `' 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".)
  9.  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.

  10.  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".)

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

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


  1. 6 Extensions to the C Language Family
  2. *************************************

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

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

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

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

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

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

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

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

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

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

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

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

  37.      debug ("A message")

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

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

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

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

  52. 6.47 Function Names as Strings
  53. ==============================

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

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

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

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

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

  67.      #if __STDC_VERSION__ < 199901L
  68.      # if __GNUC__ >= 2
  69.      # define __func__ __FUNCTION__
  70.      # else
  71.      # define __func__ ""
  72.      # endif
  73.      #endif

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

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

  80.      class a {
  81.       public:
  82.        void sub (int i)
  83.          {
  84.            printf ("__FUNCTION__ = %s\n", __FUNCTION__);
  85.            printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
  86.          }
  87.      };

  88.      int
  89.      main (void)
  90.      {
  91.        a ax;
  92.        ax.sub (0);
  93.        return 0;
  94.      }

  95. gives this output:

  96.      __FUNCTION__ = sub
  97.      __PRETTY_FUNCTION__ = void a::sub(int)

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

  104. 6.55 Other Built-in Functions Provided by GCC
  105. =============================================

  106.  -- Built-in Function: int __builtin_FUNCTION ()
  107.      This function is the equivalent to the preprocessor `__FUNCTION__'
  108.      macro and returns the function name the invocation of the built-in
  109.      is in.
ANSI C与C89、C99、C11区别差异
GNU C 与 ANSI C 的一些差别

阅读(1654) | 评论(0) | 转发(0) |