What is on topic here

[Seebs]

The same as everyone else's, of course.

Well, I sort of assumed that, but I wondered if he had something special
in mind.

No reason. But I don't recall you making similar comments in response
to assertions that comp.lang.c is for discussions of standardised C
only. Should only those with that view assert it?

I think anyone expecting other people to accept their pronouncements
should.

Comp.lang.c is for discussion of the C language, including common
implementations and related tools (especially those on unix, where it
originated).

While this is certainly a conceivable topic for a newsgroup, I don't
see any evidence that this was the topic intended for comp.lang.c when
it was created.

Maybe the right thing to do is just do an RFC and get a charter approved
for comp.lang.c. The tricky part, historically, has been that C is used
widely enough that a great deal of content which is tangentially C-related
is of no interest to most C programmers.

If we allow anything that has the word "C" somewhere in a description of
what we're talking about, everyone who is interested in C can post topically,
but most of the posts will be uninteresting to them. If we allow only things
that are very narrowly and strictly about C89, nearly any C programmer will
find the discussion relevant, but there won't be very much of it.

The historical compromise has been to stick with the language (including
C78, C89, C99, C0X), but not to include implementation-specific details,
extensions, etcetera.

There are a handful of common examples of things which are currently
generally regarded as being off-topic. I'll review those.

1. gcc questions.
2. GNU C questions.
3. Borland Turbo C questions.
4. Visual C questions.
5. UNIX API questions (sockets, etc.)
6. Windows API questions.
7. "C++ as a better C" questions.
8. make and makefile issues.

(For whatever reason, the Objective-C users never seem to come here.)

1. gcc questions.

This is the category of questions like "how do I enable warnings" and similar
questions. The recent example would be frank asking for help using the
preprocessor. These questions are clearly much more topical in gnu.gcc.help
than they are here, IMHO. I think it would make the most sense for these
questions to be routed there, simply because they'll get better responses.
There's usually more overlap between these questions and similar questions
about g77, g++, and so on, in any event.

2. GNU C questions.

By contrast with gcc questions, these are questions about the GNU C language.
Because Intel's now implementing some of this, this isn't really specific to
gcc anymore. These questions could indeed be addressed in gnu.gcc.help, but
icc users might not think to look there. Also, often what's most of interest
is the question of how these features related to, say, similar features in
C99. (Consider a discussion on the semantic differences between GNU C89
inline functions and C99 inline functions.)

Which is to say, I think this is probably the best group for these questions;
they are fundamentally about the language, not about how to use a particular
program, they apply to multiple implementations and environments (you can
use GNU C in several different operating systems), and they are tied in to
the language in general.

3. Borland Turbo C questions.

Specifically, <graphics.h> and <conio.h>. I suspect these are still best
suited to comp.os.msdos.programmer -- but they've been durable enough that
it's hard to be sure. They do seem essentially fixed to a DOS-like
environment, and I've never heard of them being implemented elsewhere. The
big surprise, I think, would be that people using these programs on Windows
might not realize that they're interacting with the faux DOS environment.

4. Visual C questions.

I've yet to see one of these that wasn't more like a gcc question than a GNU
C question -- that is to say, a question solely about how to use the program,
rather than about the language it implements. (Except in that usage can
change what language it implements.)

5. UNIX API questions (sockets, etc.)

I work in this stuff all the time, so it's certainly relevant to me, but
fundamentally, it just isn't C-related. The questions I have about the
UNIX APIs are the same questions I have when I'm using them from perl or
Ruby. There's a perfectly good UNIX programmer newsgroup, and I think these
belong there.

6. Windows API questions.

Ditto, except that it's not particularly relevant to me. Certainly, there's
a better group.

7. "C++ as a better C" questions.

By consensus, this has been understood to belong in comp.lang.c++. Seems
fair to me.

8. make and makefile issues.

I am a little torn on this, because of course, this is my primary way of using
C, but it's also my primary way of using several other languages. I would
tend to think that comp.unix.shell or one of the similar groups would be a
better fit. There's enough differences between make implementations that
a platform-specific group is probably better anyway in most cases.

.... So, thinking about it, I guess my belief is this: I think it makes sense
to allow and/or encourage discussion of extensions to the *language* here, but
not extensions to the *library* unless they are by nature portable. Jacob
Navia's container library is clearly topical here. Curses isn't.

Other people have thoughts on this?

-s

 

[Jens Thoms Toerring]

Comp.lang.c is for discussion of the C language, including common
implementations and related tools (especially those on unix, where it
originated).

Could you be so kind to define this somewhat more precisely?
I have no idea what exactly you mean with this and thus fol-
low this question with some elaborations of mine to give you
some hints what I am thinking and thus may not understand of
aboy your statement.

Take e.g. 'make'. It could be seen as such a tool (Jacob Navia
obviously does), but then 'make' can be (and is) used to do lots
and lots of things completely unrelated to compiling C programs.
And dozends of other tools come to mind that can be employed in
the compilation of C programs, so where to draw the line? More-
over, if someone is having troubles with 'make' (s)he will find
quite good support in comp.unix.programmer (and the same holds
for other UNIX tools), so I would prefer to have them discussed
over there. It's the same, of course, for Windows specific tools
- I don't think it would be useful to have long discussions here
on how to set up a "project" with a certain IDE in order to get
some stuff compiled with this special tool when there are other
places where this is one of the main topics.

Concerning common implementations: I don't mind at all if some-
one points out that some implementation does things this way or
some other way, using the leeway given by the C standard. This
can actually be very useful to make one aware of where expecta-
tions one may have derived from using only a small subset of the
available implementations can lead one astray. But for a full
blown discussion of how to do certain things with a certain im-
plementation clc IMHO isn't the right place - especially since
"common implementations" typically have their own newsgroups or
mailing lists etc. It might actually be more difficult for users
of *uncommon implementations* to find a good place to find the
informations they may be looking for;-)

My take on non-directly-C-related questions (including tools or
special features of implementations) is that those should be re-
directed to the proper places by those that feel to be experts
enough on the subject to know what the proper newsgroup/mailing
list is to be found, with perhaps one or two sentences hinting
at what's the most likely correct answer if such a short answer
is possible and seems to be likely to help the OP. In cases where
it's a mixture of a C-related questions with system/library/tool-
specific ones it should be pointed out as clearly as possible
where the borders are and an answer should concentrate as far as
possible on the C-aspects, in the end I think this will be more
helpful for the OP: while (s)he may not get everything on a silver
platter, it will help her/him to develop a mental picture of where
things belong to and thus save her/him from spending much time loo-
king in the wrong direction in the long run.

Regards, Jens

 

[spinoza1111]

From:spinoza1111<[email protected]>
Newsgroups: comp.lang.c
Subject: C as deep blasphemy
Date: Wed, 30 Dec 2009 02:56:54 -0800 (PST)

From:spinoza1111<[email protected]>
Newsgroups: comp.lang.c
Subject: Comparision of C Sharp and C performance
Date: Sun, 27 Dec 2009 06:36:54 -0800 (PST)

From:spinoza1111<[email protected]>
Newsgroups: comp.lang.c
Subject: C is NOT significantly more efficient than C Sharp
Date: Sun, 27 Dec 2009 02:50:15 -0800 (PST)

From:spinoza1111<[email protected]>
Newsgroups: comp.lang.c
Subject: Peter Seebach's behavior as "moderator" of comp.lang.C
Date: Fri, 25 Dec 2009 04:04:15 -0800 (PST)

From:spinoza1111<[email protected]>
Newsgroups: comp.lang.c,comp.programming
Subject: Richard Heathfield's lie
Date: Thu, 24 Dec 2009 09:14:51 -0800 (PST)

etc, etc...

Of course, the last time someone claimed they couldn't find his posts,
he threatened them with libel.

Note that I start on topic, but am disrupted by personal attacks. This
is because the regulars here are not qualified programmers. Heathfield
has worked on corporate teams in which one goal is to mutually cover
up for inadequacy (and note that there is nothing wrong with this):
Heathfield scored low on an objective test in the related language C+
+. Seebs has told us that on the job he does not actually program, but
finds bugs and sends them on. Seebs, to his credit, also seems to be a
good script kiddie, but with comments like "the 'heap' is a DOS term",
he makes his limitations clear.

Heathfield, Seebs et al. seem to have memorized the standard even as
we learned Latin in high school: a dead language and a set of rules
more reflective of one grammarian's views, and the dead hand of the
Church, than of praxis. Indeed, their not wanting to assign meaning to
void as a pointer is starkly similar to the ways in which grammarians
(who as taxonomists are pre-scientific) tell us we "must" use silly
and non-orthogonal rules such as who/whom.

As to the libel charge. Heathfield made the malicious claim which he
knew to be false that I'd not been accepted by the strictly and
intelligently moderated group comp.risks. I have initiated legal
action on this matter.

 

[spinoza1111]

Point out one thread started by Mr. Nilges.

Thank you.

I have started technical and meta threads. The technical threads,
which are started first, have been disrupted by Heathfield since 1999,
when he lost control of a popular discussion of programming
professionalism in comp.programming owing to his lack of education. I
have started meta-threads such as "Richard Heathfield's lie" in
egregious cases of abuse, such as claiming that I haven't published in
comp.risks. Heathfield was even called by his butt buddies on that
one.

My topic here is germane. It is the flaws of C, since they are so
serious as to mean that it should not be used.

Meta threads are necessary if people misuse this group for their own
agenda. Heathfield's is to claim a false expertise, as is Seebach, who
appears to use pseudo-professional activities (such as buying his way
on to the standards committee) in place of learning his profession.

 

[spinoza1111]

This group is about building C progreams
and the C language in general.

This includes (but is not limited to)

o linking problems
o debugging problems
o makefile problems related to the building of a c program
o compiling and compiler related questions

Most of the people that argue otherwise and want to restrict
the scope of this group are part of a small self proclaimed
group that thinks it can restrict the scope of this group
to C89.

If you look at their recent posting history you will see that
they are the principal originators of completely off topic
conversations here (the endless spinoza111 threads are a proof
of that).

To avoid clutter I will not answer any of their answers, if any.

jacob

Monsieur, whereas I have always started on topic, I also believe that
people have a right to defend their good name. And in such defense I
have generally RETURNED to the topic, for example by posting code that
other posters are too incompetent or cowardly to write, the latter
because they are afraid that they will be mocked for making trivial
errors, by clerks.

 

[spinoza1111]

Perhaps it should be, but it currently isn't.


I would say it's currently about the C language in particular. And there
are only two internationally recognised definitions of C - ISO 9899:1990
and ISO 9899:1999.



That's a view, but I think you'll find it's not a majority view. If
you're arguing that topicality should be widened, well, I agree
(although we don't necessarily agree about the direction of that
widening) - but the majority view is against us. Or at least, it was,
last time anyone bothered to check.


No, most of the people who argue otherwise are the majority of
contributors to the group. In a democracy, they win and we lose. That's
life.


If you look at the endlessspinoza1111threads, you'll see that their
off-topic aspects are principally originated byspinoza1111.


Can you also avoid clutter by shutting up about lcc-win32? This is a

Richard, children and thugs use language like that.

 

[spinoza1111]

People with inferior educations like the claim of off-topic for two
reasons:

(1) It sounds intelligent
(2) It covers up their ignorance

And principally egged on by Richard Heathfield!

You are very close to admitting that Heathfield is the problem person
here. In environments where bullies and enablers can be removed I have
a very good reputation, including wordpress and facebook. I helped to
set courtesy standards by precept and example at Princeton, but I
don't take shit.

 

[spinoza1111]

Actually, once I figured out that he was essentially incapable of processing
data in a functional way, I plonked him and stopped responding.  That woulda
been weeks ago, I think.

You little weasel, you know that I see this shit. Your behavior is
that of the drunk or wasto at the party who turns away from someone
else and loudly insults him to a third party.

What an asshole.

So I don't think I count as a facilitator now.  I tried to argue with him
for a while, tried to plumb the madness for a while in the hopes that it
would at least yield interesting ways of being wrong about C, and then
concluded that the marginal cost of getting an interesting observation from
arguing with him was too high to justify it.

The translation is you lost the argument.

 

[spinoza1111]

I disagree, as I've said at length in the past.



At least two regular posters have participated in pointless debates

Translation: "I have a masters degree",

"I have a MASTER'S degree" - Ask Mister Science, Duck's Breath Mystery
Theater

"but it is incomprehensible to me how this guy could know my trade and
so much else besides about art and shit. Therefore, he don't know shit
about my trade, I do, and I must destroy his credibility."

 

[frank]

snip

While this is certainly a conceivable topic for a newsgroup, I don't
see any evidence that this was the topic intended for comp.lang.c when
it was created.

Maybe the right thing to do is just do an RFC and get a charter approved
for comp.lang.c. The tricky part, historically, has been that C is used
widely enough that a great deal of content which is tangentially C-related
is of no interest to most C programmers.

If we allow anything that has the word "C" somewhere in a description of
what we're talking about, everyone who is interested in C can post topically,
but most of the posts will be uninteresting to them. If we allow only things
that are very narrowly and strictly about C89, nearly any C programmer will
find the discussion relevant, but there won't be very much of it.

The historical compromise has been to stick with the language (including
C78, C89, C99, C0X), but not to include implementation-specific details,
extensions, etcetera.

There are a handful of common examples of things which are currently
generally regarded as being off-topic. I'll review those.

1. gcc questions.
2. GNU C questions.
3. Borland Turbo C questions.
4. Visual C questions.
5. UNIX API questions (sockets, etc.)
6. Windows API questions.
7. "C++ as a better C" questions.
8. make and makefile issues.

(For whatever reason, the Objective-C users never seem to come here.)

1. gcc questions.

This is the category of questions like "how do I enable warnings" and similar
questions. The recent example would be frank asking for help using the
preprocessor. These questions are clearly much more topical in gnu.gcc.help
than they are here, IMHO. I think it would make the most sense for these
questions to be routed there, simply because they'll get better responses.
There's usually more overlap between these questions and similar questions
about g77, g++, and so on, in any event.

I think a lot of it is a sense of measure. I'm writing a program in
standard C that is getting hung up because I'm using an implementation
and platform that easily trips me on occasion. So it's fundamentally
about C, and because everything *MUST* happen on an implementation and
platform, well the specifics of this little thing that is a bump in the
road to me is not understanding the switches.

If I had said, is "stopping after the preprocessing stage; not running
the compiler proper, whilst the preprocessed source code is sent to
stdout" something that you can do in standard C, is not the answer
emphatically, "yes?"

 

[Colonel Harlan Sanders]

As to the libel charge. Heathfield made the malicious claim which he
knew to be false that I'd not been accepted by the strictly and
intelligently moderated group comp.risks. I have initiated legal
action on this matter.

No you haven't.

 

[Seebs]

I think a lot of it is a sense of measure. I'm writing a program in
standard C that is getting hung up because I'm using an implementation
and platform that easily trips me on occasion. So it's fundamentally
about C, and because everything *MUST* happen on an implementation and
platform, well the specifics of this little thing that is a bump in the
road to me is not understanding the switches.

Sort of. Many of those switches would be the same if you were using
the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
mode) or C++.

If I had said, is "stopping after the preprocessing stage; not running
the compiler proper, whilst the preprocessed source code is sent to
stdout" something that you can do in standard C, is not the answer
emphatically, "yes?"

Not really. It's true of most existing systems, in fact, all I know of,
but it's not *required*. If I were to implement a compiler in which
the phases of translation all occurred in memory, and the results of
the "preprocessing" phases were implemented, not actually as pure text,
but as a linked list of structures containing things which had been
turned into tokens, well, that would probably be permitted. Indeed,
there's not strictly a requirement that I actually implement the phases
of translation *AT ALL* -- as long as you can't tell, by looking only
at the final output, that I didn't do them as described.

So that's the thing. Standard C isn't an implementation. It is up
to the implementation how much visibility to offer into its internals;
there's no more guarantee of preprocessed output than there is of
assembly output. (And yes, I've used a compiler which didn't really
have assembly output -- you could get it to generate assembler, but that
would not necessarily yield the same binary code that you would get by
running it normally, because it really worked from a sort of intermediate
representation.)

-s

 

[frank]

The reason you don't remember Richard Heathfield (or any one) trying to
restrict the group to C89 is that no one has tried to do that. It is
Jacob miss-representing what other people have said, which is that there
are still very few C99 implementations, so C89/C90/C95 is more portable,
and it is useful for people to know when they are restricting portability.

Jacob's got some exotic opinions about his persecutors. What I *do* see
from Richard, time and time again, are specific dates and numbers on
revisions of many standards, especially C's.

A lot of companies use MS VCC for compiling C code, and that does not
implement C99, so earlier (theoretically obsolete) versions of the C
standard are still very important. I'm hoping that the new stuff being
put in to C1x will be enough to kick MS in to moving forward and
implementing the current standard, which would probably push other
companies in to supporting it.

Well I don't know how they're figuring on moving forward, but they've
done everything to alienate me as a customer since the early nineties.

The last time I tried to re-ignite that M$ spark, Jack Klein had
promised a free c99 M$ compiler at some link. It's bundled with 800
megs of computer pollution. Sometimes that which is "free" is incurring
costs other than monetary ones.

 

[frank]

Sort of. Many of those switches would be the same if you were using
the same toolset to work on, say, FORTRAN (and yes, gcc has a FORTRAN
mode) or C++.

Really? What's it called?

Not really. It's true of most existing systems, in fact, all I know of,
but it's not *required*. If I were to implement a compiler in which
the phases of translation all occurred in memory, and the results of
the "preprocessing" phases were implemented, not actually as pure text,
but as a linked list of structures containing things which had been
turned into tokens, well, that would probably be permitted. Indeed,
there's not strictly a requirement that I actually implement the phases
of translation *AT ALL* -- as long as you can't tell, by looking only
at the final output, that I didn't do them as described.

How does gcc do it if not with C?

 

[spinoza1111]

Translation: "I have a masters degree",

"I have a MASTER'S degree" - Ask Mister Science, Duck's Breath Mystery
Theater

"but it is incomprehensible to me how this guy could know my trade and
so much else besides about art and shit. Therefore, he don't know shit
about my trade, I do, and I must destroy his credibility."

Insistence on the truth of a taxonomy ("void is not a pointer") is in
fact prescientific. Clerks, subject to brutal corporate discipline,
reverse enlightenment to a stage before. We can't let them actually
program (let them log on to comp.lang.c and tear at each other
instead, on company time), for they under our hegemony have lost the
ability to think critically, as witness their touching loyalty to an
out of date programming language for losers. Let them instead form
scholastic theories which allow us to continue to rule zee verld.

"So that, in truth, Thou didst Thyself lay the foundation for the
destruction of Thy kingdom, and no one is more to blame for it. Yet
what was offered Thee? There are three powers, three powers alone,
able to conquer and to hold captive for ever the conscience of these
impotent rebels for their happiness those forces are miracle, mystery
and authority."

- Dostoevsky, The Brothers Karamazov

In my book "Build Your Own .Net Language and Compiler" (Edward G.
Nilges, Apress 2004) I show how two different yet equivalent grammars
could have different effects (left associative v right associative),
and this shows that grammars are pre-scientific, like biology before
Darwin (is a fungi a plant or an independent genus?).

The problem is that everything is related to everything else and that,
strictly speaking, nothing is off-topic:

"The time has come," the Walrus said,
"To talk of many things:
Of shoes--and ships--and sealing-wax--
Of cabbages--and kings--
And why the sea is boiling hot--
And whether pigs have wings."

This is especially true in the ethical register:

"It's not my business," Scrooge returned. "It's
enough for a man to understand his own business, and
not to interfere with other people's. Mine occupies
me constantly. Good afternoon, gentlemen!"

In other words, Scrooge rules neat lines around his "business" as do
people here in order as do people here to evade his responsibility to
others (as do people here).

The irrationality of such "topicality" is in the fact that concepts
form a space (far more important than cyberspace). As Kant saw, it is
essential to space that it be possible to voyage from any point in any
one space to any other point.

[Possible that is in principle, which is why we're always fascinated
by devices for intergalactic travel such as wormholes. And, arguably,
the Hubble space telescope gives us this capability in a partial sense
already. Seeing is part of the way to being there.]

This means that using language, a wormhole or pathway can be built
between apparently "unrelated" topics. The most striking example being
that before 1974, underarm deodorant had nothing to do with the South
Pole, but then it was found that its propellants released compounds
which destroyed the ozone layer starting at the South Pole.

However, one IS responsible for constructing and not just
hypothesizing the wormhole, and this is difficult for those who labor,
as do so many here, to either construct or understand a thought of
parse tree depth order > small n. This is why they are so ready to say
"shut up" to a real pro like Navia as Heathfield says like a child.

I would say that C and global warming would be an appropriate topic
here, as long as the discussion started responsibly with content about
C: of course, it is true here that boys who've never grown up because
they got cozy techie jobs which they stab others in the back to keep
don't know what the adverb "responsibly" refers to, for in the
corporation, responsibility is replaced by rule-following.

Or, "C programming and Haiti". Perhaps someone here is maintaining
software designed to create shock waves in the earth as a war-fighting
weapon: some have claimed that a test of such weapon went awry and
destroyed Haiti. Of course, this is unverifiable conspiracy theory, so
another topic would be deconstructing the myth that "black people, who
are bilingual for the most part and thus provably more adaptable and
intelligent, cannot program computers and therefore our plans for
'economic development' in Haiti must force black people, many with
technical and university degrees, to work in clothing sweatshops". It
could easily be demonstrated here that many posters are so incompetent
at their trade ("the 'heap' is a DOS term") that they were hired
because of a white skin. Perhaps C is useful at covering up this fact.

Perhaps the pseudo-science of C (its contradictory claim to be
structured and safe, and low-level) creates or is appreciated by the
same sort of minds who deny evolution or global warming while holding
down techie jobs from which they speak with equal pomposity on their
trade.

Everything is related to everything else. The question is whether one
has either the insight to see this or the ability to put it into
words. Hamlet did:

"No faith, not a iot. But to follow him thether with modestie enough,
& likeliehood to lead it; as thus. Alexander died: Alexander was
buried: Alexander re-turneth into dust; the dust is earth; of earth we
make Lome, and why of that Lome (whereto he was conuer-ted) might they
not stopp a Beere-barrell? Imperiall Caesar, dead and turn'd to clay,
Might stop a hole to keepe the winde away."

Oh, that that earth, which kept the world in awe,
Should patch a Wall, t' expell the winters flaw.



Everything is related to everything else
Nothing is irrevelant to solving Holmes' crime.
The small mind protests it wants to be safe
His manager says, we have not the time.
[And for aeons in corporations they never had time.]
The great mind sees all things in a flower
The great mind finds in weakness its power.
Like water it flows where it can and it will
Ignoring the difference between dale and high hill.

Betcha didn't know I was a poet
And it probably burns your ass
That you labor long and wearily your trade so ya know it
Whilst I master your trade and at high speed I you pass.
Betcha didn't know I was a poet
Probably thought I was a jag
But I bet I can make a rhyme for "poet" and not blow it
Dareya try it if yer not "on the rag".

 

[spinoza1111]

I think a lot of it is a sense of measure.  I'm writing a program in
standard C that is getting hung up because I'm using an implementation
and platform that easily trips me on occasion.  So it's fundamentally
about C, and because everything *MUST* happen on an implementation and
platform, well the specifics of this little thing that is a bump in the
road to me is not understanding the switches.

That is why Richard Heathfield should be ejected or ostracized for
saying "shut up" to Navia apparently because lcc-win is not The Great
God C. Working C programmers need to know, when maintaining code that
does pointer arithmetic on voids, that GCC allows this, so they don't
shit their pants and unnecessarily rewrite the code when they have
GCC.

Indeed, I now wonder whether Heathfield et al. might use "standards"
to create hourly business by doing unnecessary rewrites. Could they be
so unethical? Nawwww....

 

[spinoza1111]

No you haven't.

The Colonel knows all.
The Colonel stands tall.
Like his Daddy down in Tennessee
The Colonel knows you and the Colonel knows me.

Whereas cross dressing as Dorothy I pull the shade
And lo we find Homunculus
A pimply twerp posting nonsensical twaddle
Who only gets up, to the break room to waddle.

 

[Seebs]

Really? What's it called?

There's a g77.

How does gcc do it if not with C?

It's not that it's done with or without C. You could, in standard C,
write a "preprocessor". My point is that there's no requirement that
a compiler be implemented that way; it doesn't have to have a separate
preprocessor.

-s

 

[Kaz Kylheku]

There's a g77.


It's not that it's done with or without C. You could, in standard C,
write a "preprocessor". My point is that there's no requirement that
a compiler be implemented that way; it doesn't have to have a separate
preprocessor.

The GNU C compiler does not in fact have a separate preprocessor.

It does ship with such a utility because people need it; but
it's not actually used.

C preprocessing in GCC is done by a library (libcpp) linked
right into the compiler, which returns tokens, which are data
structures, and not raw text.

I know this because I've had to debug obscure issues with ccache.

ccache is a tool that intercepts preprocessed program text as text
during compilation, and then conditionally feeds that text
back to the compiler (if it doesn't find a hit in its cache).

Differences can show up between just running the compiler on
a translation unit, and running the compiler such that the pp-tokens
are converted to text, and then running the compiler on that text.

 

[steve]

There's a g77.

g77 was dropped from GCC nearly 5 years ago. The Fortran
compiler in GCC is gfortran. BTW, the proper name of the
language is Fortran not FORTRAN. See the Fortran 95 Standard
or newer for the proper spelling of the language.

Oh, and yes, the preprocessor options are the same.