From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier To: Neil Booth Cc: Joern Rennecke , Jan Dvorak , Craig Rodrigues , gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: warning: multi-line comment (why?) Date: Tue, 26 Sep 2000 03:43:00 -0000 Message-id: <20000926124343.A17752@pcep-jamie.cern.ch> References: <20000925230543.A28863@daikokuya.demon.co.uk> <200009252218.XAA03418@phal.cygnus.co.uk> <20000925235347.A12334@daikokuya.demon.co.uk> X-SW-Source: 2000-09/msg00644.html 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 \// 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. enjoy, -- Jamie