Working of the C Preprocessor

Question

How does the following piece of code work, in other words what is the algorithm of the C preprocessor? Does this work on all compilers?

#include 

        

Answer 1

This simple replacement (first b with a and then a with 170) should work with any compiler. You should be careful with more complicated cases (usually involving stringification '#' and token concatenation '##') as there are corner case handled differently at least by MSVC and gcc.

In doubt, you can always check the ISO standard (a draft is available online) to see how things are supposed to work :). Section 6.10.3 is the most relevant in your case.

Answer 2

The preprocessor just replaces the symbols sequentially whenever they appear. The order of the definitions does not matter in this case, b is replaced by a first, and the printf statement becomes

printf("%i", a);

and after a is replaced by 170, it becomes

printf("%i", 170);

If the order of definition was changed, i.e

#define a 170
#define b a

Then preprocessor replaces a first, and the 2nd definition becomes

#define b 170

So, finally the printf statement becomes

printf("%i",170);

This works for any compiler.

Answer 3

I think you are trying to get the information how the source code is processed by compiler. To know exactly you have to go through Translation Phases. The general steps that are followed by every compiler (tried to give every detail - gathered from different blogs and websites) are below:

1. First Step by Compiler - Physical source file characters are mapped to the source character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph sequences are replaced by corresponding single-character internal representations.

2. Second Step by Compiler - Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical source lines to form logical source lines. A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character.

3. Third Step by Compiler - The source file is decomposed into preprocessing tokens and sequences of white-space characters (including comments). A source file shall not end in a partial preprocessing token or comment. Each comment is replaced by one space character. New-line characters are retained. Whether each nonempty sequence of other white-space characters is retained or replaced by one space character is implementation-defined.

4. Fourth Step by Compiler - Preprocessing directives are executed and macro invocations are expanded. A #include preprocessing directive causes the named header or source file to be processed from phase 1 through phase 4, recursively.

5. Fivth Step by Compler - Each escape sequence in character constants and string literals is converted to a member of the execution character set.

6. Sixth Step by Compiler - Adjacent character string literal tokens are concatenated and adjacent wide string literal tokens are concatenated.

7. Seventh Step by Compiler - White-space characters separating tokens are no longer significant. Preprocessing tokens are converted into tokens. The resulting tokens are syntactically and semantically analyzed and translated.

8. Last Step - All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment.

Answer 4

To get detailed info you can try gcc -E to analyse your pre-processor output which can easily clear your doubt

Answer 5

The preprocessor just replaces b with a wherever it finds it in the program and then replaces a with 170 It is just plain textual replacement.

Works on gcc.

Answer 6

It's at §6.10.3 (Macro Replacement):

6.10.3.4 Rescanning and further replacement

1) After all parameters in the replacement list have been substituted and # and ## processing has taken place, all placemarker preprocessing tokens are removed. Then, the resulting preprocessing token sequence is rescanned, along with all subsequent preprocessing tokens of the source file, for more macro names to replace.

Further paragraphs state some complementary rules and exceptions, but this is basically it.

Though it may violate some definitions of "single pass", it's very useful. Like the recursive preprocessing of included files (§5.1.1.2p4).