{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

‘ 4 ’ this indicates that the following text

Info iconThis preview shows pages 52–54. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: ‘ 4 ’ This indicates that the following text should be treated as being wrapped in an implicit extern "C" block. As an extension, the preprocessor accepts linemarkers in non-assembler input files. They are treated like the corresponding ‘ #line ’ directive, (see Chapter 6 [Line Control], page 44 ), except that trailing flags are permitted, and are interpreted with the meanings described above. If multiple flags are given, they must be in ascending order. Some directives may be duplicated in the output of the preprocessor. These are ‘ #ident ’ (always), ‘ #pragma ’ (only if the preprocessor does not handle the pragma itself), and ‘ #define ’ and ‘ #undef ’ (with certain debugging options). If this happens, the ‘ # ’ of the di- rective will always be in the first column, and there will be no space between the ‘ # ’ and the directive name. If macro expansion happens to generate tokens which might be mistaken for a duplicated directive, a space will be inserted between the ‘ # ’ and the directive name. 10 Traditional Mode Traditional (pre-standard) C preprocessing is rather different from the preprocessing spec- ified by the standard. When GCC is given the ‘-traditional-cpp ’ option, it attempts to emulate a traditional preprocessor. GCC versions 3.2 and later only support traditional mode semantics in the preprocessor, and not in the compiler front ends. This chapter outlines the traditional preprocessor semantics we implemented. The implementation does not correspond precisely to the behavior of earlier versions of GCC, nor to any true traditional preprocessor. After all, inconsistencies among traditional implementations were a major motivation for C standardization. However, we intend that it should be compatible with true traditional preprocessors in all ways that actually matter. 10.1 Traditional lexical analysis The traditional preprocessor does not decompose its input into tokens the same way a standards-conforming preprocessor does. The input is simply treated as a stream of text with minimal internal form. This implementation does not treat trigraphs (see [trigraphs], page 2 ) specially since they were an invention of the standards committee. It handles arbitrarily-positioned escaped newlines properly and splices the lines as you would expect; many traditional preprocessors did not do this. The form of horizontal whitespace in the input file is preserved in the output. In partic- ular, hard tabs remain hard tabs. This can be useful if, for example, you are preprocessing a Makefile. Traditional CPP only recognizes C-style block comments, and treats the ‘ /* ’ sequence as introducing a comment only if it lies outside quoted text. Quoted text is introduced by the usual single and double quotes, and also by an initial ‘ < ’ in a #include directive. Chapter 10: Traditional Mode 49 Traditionally, comments are completely removed and are not replaced with a space....
View Full Document

{[ snackBarMessage ]}

Page52 / 83

‘ 4 ’ This indicates that the following text should be...

This preview shows document pages 52 - 54. Sign up to view the full document.

View Full Document Right Arrow Icon bookmark
Ask a homework question - tutors are online