Re: Mistaken change in GCC (fwd)

["Zack Weinberg" <zackw at Stanford dot EDU>]

It seems to me that this discussion is getting overly heated.  This
will be my last word on the subject unless actual patches turn up.

On Wed, Nov 22, 2000 at 02:19:26PM -0800, Joe Buck wrote:
> > I have strong opinions on this issue.  They are:
> >
> > 1. The purpose of -traditional is exactly to simulate the limitations
> >    of the historic pre-standard C compiler and preprocessor, and
> >    therefore to make it possible to compile pre-standard C code on
> >    modern systems.
> 
> This opinion is misinformed to the point of being downright ignorant,
> because you are not taking into account what traditional C preprocessors
> have been used for for the last 20 years.  Specifically, they've
> been used to preprocess text that is, in no way, C.  This is the Unix
> way, we reuse our tools.

...

Please note that I never said we didn't need a traditional
preprocessor capable of handling text which is not C.  I only said
that supporting this is, in my opinion, less important than supporting
compilation of standard-conforming C.  This is the GNU _Compiler_
Collection project, after all.

It may well be that traditional mode is more often used to preprocess
Makefiles and so on, these days, than actual K+R C.  In that case I
take back what I said about system headers.  I don't have any numbers
either way.

> > 2. Support for preprocessing things which are not C is much lower
> >    priority than support for preprocessing C.
> 
> Says who?  You?  Why do you decide?  Processing non-C is important even
> for GCC; as I said, Fortran uses it.

It is my understanding that this mechanism is rarely used by the
community of Fortran users, and that those who do are happy with the
present traditional preprocessor.

> > I am working on a revision to the cpp manual which will clarify the
> > questions about what -traditional does or does not do.
> 
> Don't waste your time rewriting the manual just yet.
> 
> You are confused about your role in this project.  You may make
> contributions, and the steering committee may choose to accept or
> reject such contributions.  I'm grateful for all of your contributions,
> but if we have to take your attitude along with them, well ...
> 
> Documented features may not be removed from gcc without the agreement of
> 3/4 of the steering committee.  Period.  You are proposing to remove
> features.  Are you sure that you have the votes?

Excuse me, I have never heard this before.  It was my understanding
that I could delete documented features on my own authority as cpp
maintainer.  If steering committee consensus is required, this should
be publicized somehow.

If the SC feels that it is essential to restore #assert to tradcpp, I
won't stand in the way.  I must continue to respectfully disagree,
however.

> Also, in effect you told the guy who wrote the original gcc and runs the
> organization that legally owns it to go to hell.  This is not a good move.
> I suggest that you apologize.

I do apologize for my tone of voice, which was excessive.  I continue
to hold the position that this problem would be better and easier
fixed in emacs.

zw