C preprocessor

[mohdalibaig]

C preprocessor generates the expanded version of our source code. In
order to view this expanded code, I made use of the command cpp
filename.c on the dos prompt. This command generates a file of .I
extension. What does this .I stands for? Although this file can be
opened using any text editor.

 

[santosh]

C preprocessor generates the expanded version of our source code.

Well, more precisely, the preprocessor is responsible for the
translation phases one to four. The preprocessor need not be a
seperate program, though it commonly is. The different phases of
translation must seem to occur distinctly, though in actuality they
may occur simultaneously or in any other order.

In
order to view this expanded code, I made use of the command cpp
filename.c on the dos prompt.

Be aware that this command need not be available under all
implementations, though again, it commonly is.

This command generates a file of .I
extension.

Another implementation detail.

What does this .I stands for?

It's a so called file name extension. Some systems requires them while
under others they may be optional. Consult your implementation and
system's documentation for the details.

Although this file can be
opened using any text editor.

Yes. However the output of later phases of translation may not be
human readable.

 

[Mike Wahler]

C preprocessor generates the expanded version of our source code. In
order to view this expanded code, I made use of the command cpp
filename.c on the dos prompt. This command generates a file of .I
extension. What does this .I stands for?

It stands for whatever your implementation's author wants it
to stand for. My guess would be 'Intermediate'.

Although this file can be
opened using any text editor.

Well, the output of a preprocessor is text.

-Mike

 

[Richard Heathfield]

Mike Wahler said:

It stands for whatever your implementation's author wants it
to stand for. My guess would be 'Intermediate'.


Well, the output of a preprocessor is text.

I can find no such requirement in the Standard, which mandates only that
"preprocessing tokens are converted into tokens" - which could easily
be text, of course.

 

[Eric Sosman]

Richard Heathfield wrote On 03/30/07 11:42,:

Mike Wahler said:




I can find no such requirement in the Standard, which mandates only that
"preprocessing tokens are converted into tokens" - which could easily
be text, of course.

I seem to recall (but only vaguely) an example of valid
C source that could survive preprocessing only once: run it
through the preprocessor and render it as text, and you got
something that wouldn't compile, or compiled with a different
meaning. Can't recall the details, but I think pp-numbers
played a role somewhere. Anybody else remember this beast?

 

[Mike Wahler]

Mike Wahler said:


I can find no such requirement in the Standard, which mandates only that
"preprocessing tokens are converted into tokens" - which could easily
be text, of course.

I should have known some pedant would jump in.

Replying to OP's remark, "this file can be opened using any text editor,"
I suppose I should have said "apparently the output of your preprocessor
is text."

-Mike

 

[Richard Heathfield]

Mike Wahler said:

I should have known some pedant would jump in.

Aye, you should.

Replying to OP's remark, "this file can be opened using any text
editor," I suppose I should have said "apparently the output of your
preprocessor is text."

Still not quite right, since in normal circumstances the output of his
preprocessor is very likely *not* text. How about this? "If your
implementation supports an option to provide you with the result of
preprocessing your C code, it is very likely to do so in text format."

 

[Guest]

Richard Heathfield wrote On 03/30/07 11:42,:

I seem to recall (but only vaguely) an example of valid
C source that could survive preprocessing only once: run it
through the preprocessor and render it as text, and you got
something that wouldn't compile, or compiled with a different
meaning. Can't recall the details, but I think pp-numbers
played a role somewhere. Anybody else remember this beast?

The output format by different preprocessors is different, and some
will make sure to that /any/ valid program's preprocessor output will
be re-read exactly the same. A program that may fail if preprocessor
output is saved in text format is

#include <stdio.h>
#define M(x) x
#define S(x) T(x), x
#define T(x) #x
int main(void) {
int zero = 0;
printf("%s = %d\n", S(M(+)M(+)zero));
return zero;
}

 

[Eric Sosman]

Harald van Dijk wrote On 03/30/07 15:20,:

The output format by different preprocessors is different, and some
will make sure to that /any/ valid program's preprocessor output will
be re-read exactly the same. A program that may fail if preprocessor
output is saved in text format is

#include <stdio.h>
#define M(x) x
#define S(x) T(x), x
#define T(x) #x
int main(void) {
int zero = 0;
printf("%s = %d\n", S(M(+)M(+)zero));
return zero;
}

That wasn't it ... Hmmm <spends too much googletime> Aha!
It was a thread from three years ago

http://groups.google.com/group/comp.lang.c/msg/5efee5801b14df99

... and I recalled imperfectly: It was an invalid source that
became valid after preprocessing (the original was uncompilable
but the preprocessor output was compilable, not the other way
around), and pp-numbers had nothing to do with it. The original

#define CAT(a,b) a##b
#define COMMENT CAT(/,/)
COMMENT This is a comment

... didn't compile, but the (non-mandated) preprocessed text

// This is a comment

... was perfectly valid.