SEC3.hss 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144
  1. [Main]
  2. Title=Initial processing
  3. [Top]
  4. The preprocessor performs a series of textual transformations on its
  5. input. These happen before all other processing. Conceptually, they
  6. happen in a rigid order, and the entire file is run through each
  7. transformation before the next one begins. CPP actually does them
  8. all at once, for performance reasons. These transformations correspond
  9. roughly to the first three "phases of translation" described in the C
  10. standard.
  11. <OL>
  12. <LI>
  13. The input file is read into memory and broken into lines.
  14. <BR><BR>
  15. CPP expects its input to be a text file, that is, an unstructured
  16. stream of ASCII characters, with some characters indicating the end of a
  17. line of text. Extended ASCII character sets, such as ISO Latin-1 or
  18. Unicode encoded in UTF-8, are also acceptable. Character sets that are
  19. not strict supersets of seven-bit ASCII will not work. We plan to add
  20. complete support for international character sets in a future release.
  21. <BR><BR>
  22. Different systems use different conventions to indicate the end of a
  23. line. GCC accepts the ASCII control sequences <CODE>LF</CODE>, <CODE>CR
  24. LF</CODE>, <CODE>CR</CODE>, and <CODE>LF&nbsp;CR</CODE> as end-of-line markers. The first
  25. three are the canonical sequences used by Unix, DOS and VMS, and the
  26. classic Mac OS (before OSX) respectively. You may therefore safely copy
  27. source code written on any of those systems to a different one and use
  28. it without conversion. (GCC may lose track of the current line number
  29. if a file doesn't consistently use one convention, as sometimes happens
  30. when it is edited on computers with different conventions that share a
  31. network file system.) <CODE>LF&nbsp;CR</CODE> is included because it has been
  32. reported as an end-of-line marker under exotic conditions.
  33. <BR><BR>
  34. If the last line of any input file lacks an end-of-line marker, the end
  35. of the file is considered to implicitly supply one. The C standard says
  36. that this condition provokes undefined behavior, so GCC will emit a
  37. warning message.
  38. <BR><BR>
  39. </LI>
  40. <LI>
  41. If trigraphs are enabled, they are replaced by their
  42. corresponding single characters. By default GCC ignores trigraphs,
  43. but if you request a strictly conforming mode with the <B>'-std'</B>
  44. option, or you specify the <B>'-trigraphs'</B> option, then it
  45. converts them.
  46. <BR><BR>
  47. These are nine three-character sequences, all starting with <CODE>??</CODE>,
  48. that are defined by ISO C to stand for single characters. They permit
  49. obsolete systems that lack some of C's punctuation to use C. For
  50. example, <CODE>??/</CODE> stands for <CODE>\</CODE>, so <CODE>'??/n'</CODE> is a character
  51. constant for a newline.
  52. <BR><BR>
  53. Trigraphs are not popular and many compilers implement them incorrectly.
  54. Portable code should not rely on trigraphs being either converted or
  55. ignored. If you use the <B>'-Wall'</B> or <B>'-Wtrigraphs'</B> options,
  56. GCC will warn you when a trigraph would change the meaning of your
  57. program if it were converted.
  58. <BR><BR>
  59. In a string constant, you can prevent a sequence of question marks from
  60. being confused with a trigraph by inserting a backslash between the
  61. question marks. <CODE>&quot;(??\?)&quot;</CODE> is the string <CODE>(???)</CODE>, not
  62. <CODE>(?]</CODE>. Traditional C compilers do not recognize this idiom.
  63. <BR><BR>
  64. The nine trigraphs and their replacements are
  65. <PRE>Trigraph: ??( ??) ??&lt; ??&gt; ??= ??/ ??' ??! ??-
  66. Replacement: [ ] { } # \ ^ | ~
  67. </PRE>
  68. </LI>
  69. <LI>
  70. Continued lines are merged into one long line.
  71. <BR><BR>
  72. A continued line is a line which ends with a backslash, <CODE>\</CODE>. The
  73. backslash is removed and the following line is joined with the current
  74. one. No space is inserted, so you may split a line anywhere, even in
  75. the middle of a word. (It is generally more readable to split lines
  76. only at white space.)
  77. <BR><BR>
  78. The trailing backslash on a continued line is commonly referred to as a
  79. <U>backslash-newline</U>.
  80. <BR><BR>
  81. If there is white space between a backslash and the end of a line, that
  82. is still a continued line. However, as this is usually the result of an
  83. editing mistake, and many compilers will not accept it as a continued
  84. line, GCC will warn you about it.
  85. <BR><BR>
  86. </LI>
  87. <LI>
  88. All comments are replaced with single spaces.
  89. <BR><BR>
  90. There are two kinds of comments. <U>Block comments</U> begin with
  91. <CODE>/*</CODE> and continue until the next <CODE>*/</CODE>. Block comments do not
  92. nest:
  93. <PRE>/* this is /* one comment */ text outside comment
  94. </PRE>
  95. <U>Line comments</U> begin with <CODE>//</CODE> and continue to the end of the
  96. current line. Line comments do not nest either, but it does not matter,
  97. because they would end in the same place anyway.
  98. <PRE>// this is // one comment
  99. text outside comment
  100. </PRE>
  101. </LI>
  102. </OL>
  103. It is safe to put line comments inside block comments, or vice versa.
  104. <PRE>/* block comment
  105. // contains line comment
  106. yet more comment
  107. */ outside comment
  108. // line comment /* contains block comment */
  109. </PRE>
  110. But beware of commenting out one end of a block comment with a line
  111. comment.
  112. <PRE> // l.c. /* block comment begins
  113. oops! this isn't a comment anymore */
  114. </PRE>
  115. Comments are not recognized within string literals. <CODE>&quot;/*&nbsp;blah
  116. */&quot;</CODE> is the string constant <CODE>/*&nbsp;blah&nbsp;*/</CODE>, not an empty string.
  117. <BR><BR>
  118. Line comments are not in the 1989 edition of the C standard, but they
  119. are recognized by GCC as an extension. In C++ and in the 1999 edition
  120. of the C standard, they are an official part of the language.
  121. <BR><BR>
  122. Since these transformations happen before all other processing, you can
  123. split a line mechanically with backslash-newline anywhere. You can
  124. comment out the end of a line. You can continue a line comment onto the
  125. next line with backslash-newline. You can even split <CODE>/*</CODE>,
  126. <CODE>*/</CODE>, and <CODE>//</CODE> onto multiple lines with backslash-newline.
  127. For example:
  128. <PRE>/\
  129. *
  130. */ # /*
  131. */ defi\
  132. ne FO\
  133. O 10\
  134. 20
  135. </PRE>
  136. is equivalent to <CODE>#define&nbsp;FOO&nbsp;1020</CODE>. All these tricks are
  137. extremely confusing and should not be used in code intended to be
  138. readable.
  139. <BR><BR>
  140. There is no way to prevent a backslash at the end of a line from being
  141. interpreted as a backslash-newline. This cannot affect any correct
  142. program, however.