Is the output of the preprocessor deterministic ?

[spibou]

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ? If not then how much variation is allowed ? Is it
just a bit more or less white space here and there or could could
there be larger differences ?

If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly
by another compiler ?

Spiros Bousbouras

[Tom St Denis]

sp****@gmail.com wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ? If not then how much variation is allowed ? Is it
just a bit more or less white space here and there or could could
there be larger differences ?

If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly
by another compiler ?

Shooting in dark...

But whitespace shouldn't stop one compiler from working with the output
from a competitor.

I think though you'll find it isn't going to be the same. For example,
if you use cpp from GCC on a Linux box then compare it to what MSVC
would give the outputs will differ, especially since the headers
themselves are different.

Tom

[spibou]

Tom St Denis wrote:

sp****@gmail.com wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ? If not then how much variation is allowed ? Is it
just a bit more or less white space here and there or could could
there be larger differences ?

If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly
by another compiler ?

Shooting in dark...

But whitespace shouldn't stop one compiler from working with the output
from a competitor.

I think though you'll find it isn't going to be the same. For example,
if you use cpp from GCC on a Linux box then compare it to what MSVC
would give the outputs will differ, especially since the headers
themselves are different.

I specified that the input has to be the same. By that I also meant
same headers.

[pete]

sp****@gmail.com wrote:

Tom St Denis wrote:

I think though you'll find it isn't going to be the same.

I specified that the input has to be the same. By that I also meant
same headers.

#include <stdio.h>

#ifdef putchar
#define STRING "putchar is a macro"
#else
#define STRING "putchar is not a macro"
#endif

--
pete

[Harald van Dijk]

sp****@gmail.com wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?
Even if you ignore that there is no standard file format for
preprocessed output, and that preprocessed output need not be
obtainable at all, then no, output may be very different.
If not then how much variation is allowed ? Is it
just a bit more or less white space here and there or could could
there be larger differences ?

Much larger. Some easy examples:

#ifndef __i386__
#error
#endif

#if 18446744073709551615U + 1
#error
#endif

#define f(x) g
#define g(x) f
f(1)(2)(3) /* either f(3) or g */

#define s(x) #x
s("\u0040") /* either "\"\u0040\"" or "\"\\u0040\"" */

[Al Balmer]

On Sun, 25 Jun 2006 13:55:23 GMT, pete <pf*****@mindspring.com> wrote:

sp****@gmail.com wrote:

Tom St Denis wrote:

> I think though you'll find it isn't going to be the same.

I specified that the input has to be the same. By that I also meant
same headers.

#include <stdio.h>

#ifdef putchar
#define STRING "putchar is a macro"
#else
#define STRING "putchar is not a macro"
#endif

He said "same headers", not "headers with the same name."

But Harald has a couple of examples.

--
Al Balmer
Sun City, AZ

[spibou]

Harald van Dijk wrote:

sp****@gmail.com wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?

#define f(x) g
#define g(x) f
f(1)(2)(3) /* either f(3) or g */

Ok , let's concentrate on this one for the time being. The
Sun compiler gives " g (2)(3) " (without the quotes). GNU
gives "g". Could someone explain to me the intermediate
steps which give these results ? Also for "f(3)" if that's
also possible.

By the way is there a tool or option for some compiler
which will make it show all the intermediate steps in
macro expansions ? So I'm asking for something similar
to Lisp's macroexpand-1.

Spiros Bousbouras

[Barry Schwarz]

On 25 Jun 2006 06:35:42 -0700, sp****@gmail.com wrote:

Tom St Denis wrote:

sp****@gmail.com wrote:

> Is the output of the C preprocessor deterministic ? What I mean
> by that is , given 2 compilers which conform to the same standard,
> will their preprocessors produce identical output given as input
> the same file ? If not then how much variation is allowed ? Is it
> just a bit more or less white space here and there or could could
> there be larger differences ?
>
> If the output is not deterministic then is it possible that the output
> of the preprocessor of one compiler can not be processed correctly
> by another compiler ?

Shooting in dark...

But whitespace shouldn't stop one compiler from working with the output
from a competitor.

I think though you'll find it isn't going to be the same. For example,
if you use cpp from GCC on a Linux box then compare it to what MSVC
would give the outputs will differ, especially since the headers
themselves are different.

I specified that the input has to be the same. By that I also meant
same headers.

Headers are system specific. The compiler writer is allowed to take
advantage of unique system attributes. It is unreasonable to expect
one compiler to even function with another's headers. What about the
case where headers are not files but built-in to the compiler?
Remove del for email

[spibou]

Barry Schwarz wrote:

On 25 Jun 2006 06:35:42 -0700, sp****@gmail.com wrote:

Tom St Denis wrote:

sp****@gmail.com wrote:
> Is the output of the C preprocessor deterministic ? What I mean
> by that is , given 2 compilers which conform to the same standard,
> will their preprocessors produce identical output given as input
> the same file ? If not then how much variation is allowed ? Is it
> just a bit more or less white space here and there or could could
> there be larger differences ?
>
> If the output is not deterministic then is it possible that the output
> of the preprocessor of one compiler can not be processed correctly
> by another compiler ?

Shooting in dark...

But whitespace shouldn't stop one compiler from working with the output
from a competitor.

I think though you'll find it isn't going to be the same. For example,
if you use cpp from GCC on a Linux box then compare it to what MSVC
would give the outputs will differ, especially since the headers
themselves are different.

I specified that the input has to be the same. By that I also meant
same headers.

Headers are system specific. The compiler writer is allowed to take
advantage of unique system attributes. It is unreasonable to expect
one compiler to even function with another's headers. What about the
case where headers are not files but built-in to the compiler?

Then you can consider the case where you have 2 compilers on the same
platform. The essence of my original question is whether macro
expansion
rules are deterministic not about unique system attributes and
differences
in the environment.

Spiros Bousbouras

[Gordon Burditt]

>Is the output of the C preprocessor deterministic ? What I mean

by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?
There is no standardized format for the output of the preprocessor,
which is in tokens. Some may output plain text. Some may output
XML. Some may output some wierd binary format. Some may not even
HAVE a separate output format nor exist as a separate program.
If not then how much variation is allowed ? Is it
just a bit more or less white space here and there or could could
there be larger differences ?
The expansion of __TIME__ and __DATE__ may be different for successive
runs of the preprocessor. Many preprocessors have predefined symbols
indicating the type of system, OS, or compiler it is, and different
preprocessors may have different predefined symbols.

Differences in system header files may result in different output.
It is possible that some preprocessors cannot handle non-precompiled
system headers, and that others have no provision for precompiled
headers.

System headers may contain special magic, some of which might be
handled by the preprocessor. If a different preprocessor tries
to handle the magic, it may report errors, or handle it incorrectly.
If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly
by another compiler ?

Due to possible:
- Lack of output from the preprocessor stage
- Inability to input to the compiler without preprocessing AGAIN
- Differences in preprocessor/compiler formats for preprocessed tokens
- Differences in system header files

it's very possible that output from one preprocessor can't be compiled
by another compiler, and even more likely that it won't link and run
correctly.

Gordon L. Burditt

[Harald van Dijk]

sp****@gmail.com wrote:

Harald van Dijk wrote:

sp****@gmail.com wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?
#define f(x) g
#define g(x) f
f(1)(2)(3) /* either f(3) or g */

Ok , let's concentrate on this one for the time being. The
Sun compiler gives " g (2)(3) " (without the quotes). GNU
gives "g". Could someone explain to me the intermediate
steps which give these results ? Also for "f(3)" if that's
also possible.

< f(1) >(2)(3) becomes < g >(2)(3)

g is not being expanded already, so it must be considered for
expansion:

< g(2) >(3) becomes < f >(3)

g was the result of the expansion of f(1), but ( wasn't. The standard
doesn't specify whether the final f is considered the result of the
expansion of f(1) in this case. If the compiler considers it as such,
f(3) is not expanded further. If it isn't, f(3) is expanded once more
to g.

(It was a slightly modified example from the C99 rationale, by the
way.)
By the way is there a tool or option for some compiler
which will make it show all the intermediate steps in
macro expansions ? So I'm asking for something similar
to Lisp's macroexpand-1.

No idea, but if there is such a thing, I'm interested too.

[Mark McIntyre]

On 25 Jun 2006 04:01:47 -0700, in comp.lang.c , sp****@gmail.com
wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?
Its trivial to show examples which differ:

#ifdef _WIN32
#error noway hose
#else
int x=0;
#endif

But I've a feeling that isn't what you're thinking of !
If not then how much variation is allowed ?
The C preprocessor is largely a simple textual replacement engine.
Such replacements will be identical. The results of conditional code
etc will obviously vary if its intended to.
If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly
by another compiler ?

Sure - you could define a constant which was impossibly large for one
compiler, such as a 32-bit value in a 16-bit environment.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

He said "same headers", not "headers with the same name."

Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Al Balmer]

On Sun, 25 Jun 2006 21:14:32 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

He said "same headers", not "headers with the same name."

Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.

But that wasn't the question. The question, as the subject line says,
was "Is the output of the preprocessor deterministic ?". It's a
perfectly legitimate question. There's nothing that would preclude a
single preprocessor being used with more than one implementation.
Forget about header files. The question was whether every preprocessor
is required to produce the same output, given the same input. We can
stipulate that the input is syntactically correct, of course.

--
Al Balmer
Sun City, AZ

[Mark McIntyre]

On Sun, 25 Jun 2006 21:17:14 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

On Sun, 25 Jun 2006 21:14:32 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

He said "same headers", not "headers with the same name."
Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.

But that wasn't the question.

So what? I was commenting on your remark about headers.
Forget about header files.

Why? Thats what I was commenting on.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?

There is no standardized format for the output of the preprocessor,
which is in tokens. Some may output plain text. Some may output
XML. Some may output some wierd binary format. Some may not even
HAVE a separate output format nor exist as a separate program.

[snip]

The question above, "Is the output of the C preprocessor
deterministic?", was posted by Spiros Bousbouras <sp****@gmail.com>.
I mention this because Gordon Burditt is too rude to atttribute
quotations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Gordon Burditt]

>But that wasn't the question. The question, as the subject line says,

was "Is the output of the preprocessor deterministic ?". It's a
perfectly legitimate question. There's nothing that would preclude a
single preprocessor being used with more than one implementation.
Forget about header files. The question was whether every preprocessor
is required to produce the same output, given the same input. We can
stipulate that the input is syntactically correct, of course.

No, if the input uses __DATE__ or __TIME__ .

Possibly no unless you count command-line options that predefine
or pre-un-define macros as part of the input. Also possibly no
unless you count command-line options that change what system
header files are used as part of the input.

Possibly no if the name of the file given to the file is not
considered part of the input and variations of the name are used
(e.g. /home/gordon/foo.c vs. ./foo.c vs. foo.c) and the compiler
sticks the file name into the preprocessed output (__FILE__ is used
or the preprocessor sticks filename info into the preprocessed
output for use with error messages from the compiler).

Gordon L. Burditt

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

go***********@burditt.org (Gordon Burditt) writes:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?

There is no standardized format for the output of the preprocessor,
which is in tokens. Some may output plain text. Some may output
XML. Some may output some wierd binary format. Some may not even
HAVE a separate output format nor exist as a separate program.

[snip]

The question above, "Is the output of the C preprocessor
deterministic?", was posted by Spiros Bousbouras <sp****@gmail.com>.
I mention this because Gordon Burditt is too rude to atttribute
quotations.

Uh oh. Cat fight!

[Walter Roberson]

In article <11**********************@y41g2000cwy.googlegroups .com>,
<sp****@gmail.com> wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ?

Not necessarily. It isn't uncommon for preprocessors to put
in # directives that help trace which line of which header file
that one has reached. Those # directives are not necessarily
in a standard format.

The C standard does not require the possibility of
"preprocessing only": preprocessing is only defined in terms
of one of the translation phases, and the translation phases
are defined by the standard as being logical phases that may
be internally combined, and which may pass information to each
other through any mechanism they like.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[Al Balmer]

On Sun, 25 Jun 2006 22:49:27 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Sun, 25 Jun 2006 21:17:14 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

On Sun, 25 Jun 2006 21:14:32 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

He said "same headers", not "headers with the same name."

Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.
But that wasn't the question.

So what? I was commenting on your remark about headers.

No, you weren't. You said "Then the question was strictly
meaningless". I didn't ask any question, so you could not have been
commenting about that. The question was asked by the OP.

Forget about header files.

Why? Thats what I was commenting on.

Then start your own thread.

--
Al Balmer
Sun City, AZ

[Mark McIntyre]

(I apologise in advance, I propose to end this post with a small
insult, I dislike people being disingenuous without reason).

On Mon, 26 Jun 2006 06:45:08 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

No, you weren't. You said "Then the question was strictly
meaningless". I didn't ask any question, so you could not have been
commenting about that. The question was asked by the OP.

Let me get this completely straight for the record:

I was commenting that the OP's question was strictly meaningless, if
he literally meant, as you said he did, the same headers.

If this is still hard for you to understand, and frankly I suspect it
never was, I suggest you take out your obstreperous nitwit earplugs.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Al Balmer]

On Mon, 26 Jun 2006 22:00:41 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

(I apologise in advance, I propose to end this post with a small
insult, I dislike people being disingenuous without reason).
Odd. I was thinking the same about your pretending not to understand
the question.

As for your apology, I'll take it in the spirit given. The same back
at you. Talk about disingenuous!
On Mon, 26 Jun 2006 06:45:08 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

No, you weren't. You said "Then the question was strictly
meaningless". I didn't ask any question, so you could not have been
commenting about that. The question was asked by the OP.

Let me get this completely straight for the record:

I was commenting that the OP's question was strictly meaningless, if
he literally meant, as you said he did, the same headers.

If this is still hard for you to understand, and frankly I suspect it
never was, I suggest you take out your obstreperous nitwit earplugs.

--
Al Balmer
Sun City, AZ

[Peter Nilsson]

Keith Thompson wrote:

go***********@burditt.org (Gordon Burditt) writes: <snip>
The question above, ... was posted by <snip>
I mention this because Gordon Burditt is too rude to atttribute
quotations.

Gordon never posts attirbutions, AFAIK. But I'm not sure why it
would (or should) be considered rude.

Every netiquette guide talks about how to properly give attributions,
but I've yet to see a rationale for why attributions are considered
mandatory. Getting them wrong certainly causes problems, but
leaving them out altogether?!

I don't know Gordon's justification, but I can understand an ethos that
it doesn't really matter who posted what so long as the central issue
is
what is being addressed. Perhaps Gordon feels that leaving out
the attributions actually encourages people (or at least himself)
to focus on the issue. ["Watch the ball, not the man."]

If anything, not giving attributions is one form of preventing the
misunderstandings on who said what. And because it's harder to
directly see who said what, you're less likely to focus on the
who, and more likely to focus on the what.

That said, I'll continue to include attributions. If only for reasons
that I can't quite put my finger on!

--
Peter

[Keith Thompson]

"Peter Nilsson" <ai***@acay.com.au> writes:

Keith Thompson wrote:

go***********@burditt.org (Gordon Burditt) writes:

<snip>

The question above, ... was posted by <snip>
I mention this because Gordon Burditt is too rude to atttribute
quotations.

Gordon never posts attirbutions, AFAIK. But I'm not sure why it
would (or should) be considered rude.

It was discussed here at some length not too long ago.

Attributions make it easier to follow conversations. Gordon's claims
about why he deliberately snips them were, in my humble opinion,
unconvincing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Al Balmer]

On 26 Jun 2006 20:45:39 -0700, "Peter Nilsson" <ai***@acay.com.au>
wrote:

Keith Thompson wrote:

go***********@burditt.org (Gordon Burditt) writes:

<snip>

The question above, ... was posted by <snip>
I mention this because Gordon Burditt is too rude to atttribute
quotations.

Gordon never posts attirbutions, AFAIK. But I'm not sure why it
would (or should) be considered rude.

Odd. I don't understand why using someone else's words without
acknowledging the author could not be rude, unless he has asked for
anonymity. Worse, the practice makes it appear as if the current
author is claiming the writing as his own.

--
Al Balmer
Sun City, AZ

[Mark McIntyre]

On 26 Jun 2006 20:45:39 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:

Keith Thompson wrote:

go***********@burditt.org (Gordon Burditt) writes:

<snip>

The question above, ... was posted by <snip>
I mention this because Gordon Burditt is too rude to atttribute
quotations.

Gordon never posts attirbutions, AFAIK. But I'm not sure why it
would (or should) be considered rude.

Its very important to know who said what. For example, I'd trust Chris
Torek more than I'd trust spinosa999, and hence I'd want to know who
Gordon were responding to, so that I could weigh his words
appropriately.

And personally, I dislike my words being quoted without my name
attached. If I say something dumb, I want people to know so they can
correct me. If I say something smart, likewise. And I don't like the
possibility that words might be mistaken for mine, or confused with
mine, or confused with someone elses. It feels kinda like claiming
someone else's work for your own.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Al Balmer <al******@att.net> writes:

On 26 Jun 2006 20:45:39 -0700, "Peter Nilsson" <ai***@acay.com.au>
wrote:

Keith Thompson wrote:

go***********@burditt.org (Gordon Burditt) writes:

<snip>

The question above, ... was posted by <snip>
I mention this because Gordon Burditt is too rude to atttribute
quotations.

Gordon never posts attirbutions, AFAIK. But I'm not sure why it
would (or should) be considered rude.

Odd. I don't understand why using someone else's words without
acknowledging the author could not be rude, unless he has asked for
anonymity. Worse, the practice makes it appear as if the current
author is claiming the writing as his own.

It doesn't *quite* do that; the "> " and ">> " prefixes make it clear
enough that the material is quoted. But deliberately snipping
attributions is certainly rude, Gordon's questionable excuses
notwithstanding.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Mark McIntyre wrote:

If I say something dumb, I want people to know so they can
correct me. If I say something smart, likewise.

OK, but it will require sophistry when you say something smart.

--
pete

[spibou]

Mark McIntyre wrote:

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

He said "same headers", not "headers with the same name."

Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.

Why not ? Note that I never stipulated that the output of
the preprocessor has to be compilable.

[Skarmander]

sp****@gmail.com wrote:

Is the output of the C preprocessor deterministic ? What I mean
by that is , given 2 compilers which conform to the same standard,
will their preprocessors produce identical output given as input
the same file ? If not then how much variation is allowed ? Is it
just a bit more or less white space here and there or could could
there be larger differences ?

If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly
by another compiler ?

I've read the entire thread, and yet the thing I'd imagine people mentioned
first is not mentioned at all -- at least not directly. Maybe because it's
because it's so obviously not what you want to consider.

#pragma.

You're free to amend your question to "assuming we don't use #pragma", of
course. But I'll stop here.

S.

[Keith Thompson]

pete <pf*****@mindspring.com> writes:

Mark McIntyre wrote:

If I say something dumb, I want people to know so they can
correct me. If I say something smart, likewise.

OK, but it will require sophistry when you say something smart.

I don't think that will be a problem around here.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

sp****@gmail.com writes:

Mark McIntyre wrote:

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

>He said "same headers", not "headers with the same name."

Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.

Why not ? Note that I never stipulated that the output of
the preprocessor has to be compilable.

For one thing, system headers are free to use non-portable compiler
extensions, some of which can be syntax errors for other compilers.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Harald van Dijk]

sp****@gmail.com wrote:

Mark McIntyre wrote:

On Sun, 25 Jun 2006 17:23:42 GMT, in comp.lang.c , Al Balmer
<al******@att.net> wrote:

He said "same headers", not "headers with the same name."

Then the question was strictly meaningless - you can't generally use
the same headers on different implementations.

Why not ? Note that I never stipulated that the output of
the preprocessor has to be compilable.

"If the output is not deterministic then is it possible that the output
of the preprocessor of one compiler can not be processed correctly by
another compiler ?"

How do you want to process the output of the preprocessor other than by
compiling it?