This is the mail archive of the
mailing list for the GCC project.
Re: Mistaken change in GCC (fwd)
- To: Per Bothner <per at bothner dot com>
- Subject: Re: Mistaken change in GCC (fwd)
- From: Neil Booth <neilb at earthling dot net>
- Date: Wed, 22 Nov 2000 18:43:32 +0000
- Cc: gcc at gcc dot gnu dot org, rms at gnu dot org, zackw at stanford dot edu, gerd at gnu dot org,pfeifer at dbai dot tuwien dot ac dot at, Joe Buck <jbuck at racerx dot synopsys dot com>
- References: <200011221634.IAA00088@racerx.synopsys.com> <firstname.lastname@example.org>
I'd like to add my 2 cents, as I've done a fair share of work on cpp.
Per Bothner wrote:-
> So we have some options:
> (1) Merge #cpp into the gcc-1 version of tradcpp.c. This is probably
> a lot of work.
This is the direction I prefer.
> (2) Use a gcc-2 version of cccp.c (and other files, including cexp.y)
> for tradcpp.c. That does bloat the compiler distribution a bit, and
> I guess it is more work than just dropping it in.
I don't think any of us really wants this.
> (3) Make cpplib support -traditional, removing the need for tradcpp.c.
> That presumably makes cpplib more complex, bloated and slower. In
> principle I like this better than a separate tradcpp.c program - the
> problem is how "more complex, bloated and slower" the merged program
> would be, and to what extend those problems can be mitigated, There
> is also the problem of actually doing the work to make cpplib
> implemented -traditional - support for -traditional was presumably
> removed for a reason.
I cannot stress how strongly I feel that this is the worst option. On
a scale of 0 to 10 I would rate it minus 10. We are moving towards a
fully integrated preprocessor / C compiler combination, based on
*tokens* not text, with the beginnings of precompiled headers on the
horizon. This would practically put us back to square 1.
> (4) Make a decision that #cpu is a little-used extension, and while
> we will continue to support it, we will only do so when *not* using
This doesn't look popular.
> Zack is basically saying (4), and there is something to be said for
> that. However, we have to weigh the problems of applications that
> use the extension. First, can the applications reasonably be fixed
> to not need the extension, and secondly we have the problem of people
> compiling existing or older releases.
So. I'm prepared to do the work to introduce assertions to tradcpp to
either match the current implementation in cpp0 or the one in 2.95.2.
I cannot believe it would be too hard.
However, I will only commit my time to do this if we agree now on
doing absolutely *nothing* to cpp0. cpp0 works on tokens, not text.
It lexes tokens the C way. It does not preserve the form of
whitespace. Double dots with a space between them is the least of
your problems trying to put Makefiles through it or languages other
than C derivatives and assembler. I am extremely against anything
done to cpp0 that encourages such abuse.
Also, I do not have access to my machine for about 3 wks over
Christmas, though if given the go ahead I would hope to have this
finished by then.