This is the mail archive of the
mailing list for the GCC project.
Re: CPP outputs wrong number of newlines sometimes
- To: Neil Booth <NeilB at earthling dot net>
- Subject: Re: CPP outputs wrong number of newlines sometimes
- From: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>
- Date: Tue, 26 Sep 2000 13:15:09 +0200
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <20000925215910.A16849@pcep-jamie.cern.ch> <20000925222601.A17041@pcep-jamie.cern.ch> <20000925222925.C24101@daikokuya.demon.co.uk>
Neil Booth wrote:
> Probably. I'd rather not scan the string / comment again,
> particularly if we're moving towards multibyte char support.
If it's UTF-8 output, then rescanning is ok for newlines.
> It might be better to somehow record the number of lines involved when
> lexing these tokens. That would be easy (just the difference between
> buffer->lineno before and after the relevant function call); finding
> the place to store that info would be harder.
Or just store a flag meaning "this token contains embedded newlines".
It won't be set often. Then you can scan at output time. I agree
recording the line number difference is cleanest, but it may not be
At the moment with -C, // comment tokens include the newline at end. If
you don't clear pfile->need_newline in output_token, you get output like
this with redundant newlines and line directives:
However I think that can only happen with // comments, so it would be
simpler to just fix those tokens to not include the final newline
> Don't you just love GNU extensions? <g>
I don't think this is an extension. Don't all unix preprocessors have
to do the same thing here?
> Maybe you could get the paperwork done anyway. I'm sure it'd be
> useful for the future.
Hmm. Which form, anyway? So many to choose from.