This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Mistaken change in GCC (fwd)


I fully agree with Neil that (1) is the way to go. As someone who
has, in the past, implemented -traditional behaviour in an
integrated, token oriented preprocessor, I can vouch that it is
an extremely difficult task, prone to obscure errors and corner
cases.

Most of the "features" of -traditional preprocessing (whitespace
preservation, random token pasting via adjacency and via
comments, creating comments using macro expansion, etc.) are
actually side effects of the very simple text-based
substitution/rescan algorithm used, and many more were side
effects of the compiler re-lexing the intermediate file. The best
way to implement these "features" both as a standalone
preprocessor and as a part of C compilation is to use a separate
text based implementation.

Dave

Neil Booth wrote:
> 
> 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
> > -traditional.
> 
> 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.
> 
> Neil.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]