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...)


On Thu, May 11, 2000 at 06:28:05PM -0400, Dave Brolley wrote:
> Neil Booth wrote:
> 
> > I still have a problem to fix with &&, though, since the new lexer
> > sees
> > 
> > #if 1 &/**/& 1
> > 
> > as containing a single && token.  It should be easily fixable through
> > a new TRAD_COMMENT flag for the initial & token, or suchlike, which
> > would be treated as a whitespace separator without actually outputting
> > whitespace.
> 
> Well, if the old cccp saw it as one token, as you said, then I
> don't see why you have to fix it now.

Having read the entire discussion, I think we're working much too
hard.

If I understand correctly, the problems only come up when -traditional
and -C are used simultaneously.  -traditional by itself shouldn't be a
problem, as the comments get no tokens and don't set PREV_WHITESPACE
on the next token, so paste happens normally.  Correct?

Also, the problems only come up on directive lines.  -C might prevent
two tokens from being pasted elsewhere, but that isn't a problem,
because -C output can't be fed into the compiler anyway; it's for
human consumption, and a program that reads -C mode will just have to
deal.  Also correct?

Therefore, I see no particular reason why we can't just shut off -C
when processing directives other than #define.  That means the
comments disappear, but the rest of the line's going to disappear too,
so the comments are less than helpful.

We still arguably have a problem with something like

#def/**/ine foo bar

in -C -traditional mode only.  But look at this:

% cat test.c
#def/**/ine foo bar
foo
% /lib/cpp test.c
# 1 "test.c" 
test.c: 1: undefined control

foo
% uname -a
SunOS rtl 4.1.3_U1 3 sun4m

In other words, this is too perverse for a genuine K+R preprocessor,
even without -C, so I see no reason why we should bother supporting it.

zw

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