fix #337 - line splicing in comment not handled properly

[clock999]

To fix the issue:
#337

[clock999]

Here are the corresponding links about this issue:

https://sourceforge.net/p/cppcheck/discussion/general/thread/37c6eba151/
https://github.com/danmar/simplecpp/issues/337

[danmar]

The PR title is misleading. The fix is to handle line splicing differently. simplecpp doesn't contain any uninitvar checking and there is no uninitialized variable usage I hope.

#337 is much more proper.

[danmar]

I am thinking if something like this could work:

    char lastChar = ' ';
    while (stream.good() && (lastChar == '\\' || (ch != '\r' && ch != '\n')) {
        currentToken += ch;
        lastChar = ch;
        ch = stream.readChar();
    }

[danmar]

is this the only line splicing test we have?

I think we should test what happens when there are multiple newlines after the :

//  x \\\n
\n
\n
...

and an explicit test for \r\n:

//  x \\\r\n
...

and I wonder what the behavior (according to standard / according to gcc+msvc+etc) is if there is space after the backslash:

// x \\ \n
...

[danmar]

I don't remember exactly how the location is adjusted right now. Will the locations below the line splicing comment be correct? i.e.:

// hello \
world
x=1;

will x=1; line number be 3?

[clock999]

is this the only line splicing test we have?

I think we should test what happens when there are multiple newlines after the :

//  x \\\n
\n
\n
...

and an explicit test for \r\n:

//  x \\\r\n
...

and I wonder what the behavior (according to standard / according to gcc+msvc+etc) is if there is space after the backslash:

// x \\ \n
...

Hi Danmar,

I wonder what the behavior (according to standard / according to gcc+msvc+etc) is if there is space after the backslash

I checked this with the gcc. The gcc version is 13.3.0.
If there is space after the backslash, the next line will be commented. That is different with the case there is a non-space char after the backslash.

#include <stdio.h>

int main() {
    int x;
    //abc \    
    printf("there is a space\n");
    //abc \x
    printf("there is a char x\n");
    //abc \
    printf("there is nothing\n");
    return 0;
}

Output:
there is a char x

The 1st and 3rd output both didn't happen.
Interetingly, the editor seems have a different behavior with the gcc. I used the geditor on ubuntu. The editor will display the comment line with a color of purple. But it doesn't treat the first print as a comment line.

But obviously I think we should follow the rule of the gcc.

[clock999]

I don't remember exactly how the location is adjusted right now. Will the locations below the line splicing comment be correct? i.e.:

// hello \
world
x=1;

will x=1; line number be 3?

Hi Danmar,
I made a test for how we handle the comment marked by /**/.

readfile("abc/*123\\\n456\n789*/xxx")

output:
abc /*123456789*/ xxx

If there is a '\' in the comments, all the '\n' will be erased. As the multiline is not 0, location.adjust will not be called, and 'xxx' is not a newline, so the loc of 'xxx' will not be added with the multiline.

readfile("abc/*123\n456\n789*/xxx")

output:
abc /*123
456
789*/xxx

If there is only the '\n', multiline is not set. And the loc of the next token is adjusted. The loc will be added by one with '\r', '\n' or '\r\n' in the location.adjust.

For:

// hello \
world
x=1;

According to /**/, '\\n' or '\n' will add multiline by one. As 'x=1' is on a new line, it's line number of loc will be added with the multiline. So it will be 3, which is 'location.line += multiline + 1' ,and multiline = 1. I will update the commit according to the way of handling the multiline comments.

[danmar]

thanks! good that you tested this

[danmar]

this if (!tmp.empty()) is redundant.

[danmar]

this continue is not need right?

[danmar]

this break can be removed right since the outer loop will break if stream is not good.