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: -traditional comment elimination (yuk...)


Neil Booth wrote:
> 
> Dave Brolley wrote:-
> 
> > #if 1 &/**/& 1
> >
> > causes an error because the #if line is interpreted right away by
> > the preprocessor as <#><if><1><&><&><1> and is never re-lexed by
> > the compiler.
> 
> It looks like current releases don't have this correct, then - I
> tested this on 2.95.2 and there was no error (it uses cccp, right?)
> and the #if was entered.

If cccp does this, then I have to assume that it was intentional.
I have seen this cause errors in other preprocessors though. How
about 

#if 1 &/* a longer comment */& 1

It could be that the original authors of cccp treated /**/ as an
explicit request to paste.

> 
> Just exactly how much of this do we want to get right?  Everything?
> Because getting the two cases of && you offered right means that cpp
> and front ends will not be able to share their view of the token
> streams (i.e. they cannot be easily integrated).  It looks very
> unpleasant, to say the least.

I would think that the ones you want to get right are mainly the
uses of comments to paste macro argument with other tokens in the
macro and the use of comments to paste complete macro invocations
with the text which precedes or follow. Cases like the one above
will be rare because it's obviously a contrived example. I guess
it depnds on how bad we want to compile obfuscated C contest
entries  :-)

> > It's kind of a catch 22. A token based integrated preprocessor
> > makes it easy to implement ANSI but hard to implement
> > --traditional. A text based two pass preprocessor/compiler makes
> > it easy to implement -traditional. I found this to be one of the
> > trickiest areas of the last preprocessor I worked on.
> 
> It's going to be very hard to get right, and unfortunately it looks
> like supporting -traditional is going to impede performance of the
> common, non-traditional, case.  This is not what I really wanted.

One way to get it almost completely right with little effort and
without affecting the performance of non -traditional
compilations would be to use an intermediate text file for
-traditional even when the preprocessor becomes integrated. We're
going to need this capability anyway in order to support -P and
-E.

Dave

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