This is the mail archive of the
mailing list for the GCC project.
Re: warning: multi-line comment (why?)
- To: Neil Booth <NeilB at earthling dot net>
- Subject: Re: warning: multi-line comment (why?)
- From: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>
- Date: Tue, 26 Sep 2000 12:43:43 +0200
- Cc: Joern Rennecke <amylaar at cygnus dot co dot uk>, Jan Dvorak <johnydog at go dot cz>, Craig Rodrigues <rodrigc at mediaone dot net>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <20000925230543.A28863@daikokuya.demon.co.uk> <200009252218.XAA03418@phal.cygnus.co.uk> <20000925235347.A12334@daikokuya.demon.co.uk>
Neil Booth wrote:
> Hmm, you didn't read my mail did you? :-) You've not really fixed it,
> and made it hard work. What if there's two escaped newlines in a row?
> Or if there's a trigraphed backslash? get_effective_char handles all
> that for you, rather than you checking the result of a buffer->cur++.
You didn't read my code did you? :-)
It works fine with multiple escaped newlines and trigraphs.
Read the code carefully. It doesn't do *buffer->cur++. It does
*buffer->cur. Why? See below.
> To be consistent we should also whitespace-skip \v and \f.
The coding is deliberate, though you may disagree with my choice.
I want to suppress the warning in the case of "// something
\<newline><hspace>// something else", but for all other cases the source
is quite unusual. In those cases, keep the warning. That includes \v,
\f and escaped newlines in the comment delimiter.
The test case illustrates that.
Btw, the code is pretty fast. The extra code is only executed in these
unusual cases -- the normal comment parsing code sticks to the early
part of the loop and exits quickly at the end of the line.
> No special tab handling is needed - it's only there to keep track of
> columns for warnings, and since we're a line comment there are not
> going to be any warnings on the line (trigraph warnings are now turned
> off). is_nvspace does all that for you.
> Ah, now I see what you're getting at. The \\n case reports the
> beginning of the in-progress token; missing \n reports the col number.
> Not sure it's worth changing; it's not as if the location is in any
> doubt. Do you think it's worth the extra overhead to get a correctly
> reported column number for unexpected EOF?
The code to track the column number is very, very rarely called. You
have to have an escaped newline at the end of a // comment, followed by
tab characters to reach that code. How likely is that? So forget about
the overhead; there isn't one.