Relative paths with double dot at the beginning (..\) fail in reports

[cmorve-te]

PathUtils::sanitize in sonar-plugin-api is described as "Normalize path and replace file separators by forward slash", but the only thing it does is call return FilenameUtils.normalize(path, true); (https://github.com/SonarSource/sonar-plugin-api/blob/master/plugin-api/src/main/java/org/sonar/api/utils/PathUtils.java#L42). https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/FilenameUtils.html#normalize(java.lang.String,boolean) explains that

A double dot will cause that path segment and the one before to be removed. If the double dot has no parent path segment to work with, null is returned.

So the CxxReportLocation constructor may return something with a line and a column, but a "null" file, if the "file" it's given is something like "../dir/file.c".

In https://github.com/SonarOpenCommunity/sonar-cxx/blob/master/cxx-sensors/src/main/java/org/sonar/cxx/sensors/utils/CxxIssuesReportSensor.java#L164 only the file is checked. So, probably I should not have those ../ paths in my build log to start with, but if somebody happens to have them he ends up with issues being listed in SonarQube with no location. Usually, when a file is not "known", the issue is simply ignored (https://github.com/SonarOpenCommunity/sonar-cxx/blob/master/cxx-sensors/src/main/java/org/sonar/cxx/sensors/utils/CxxReportSensor.java#L84), so there is a strange discrepancy here.

The issue can be reproduced with sonar-cxx 2.1.2 making -Dsonar.cxx.gcc.reportPaths= point to a file with something like ../file.c:1:1: warning: message [-Wdiv-by-zero] (supposing -Wdiv-by-zero is in the quality profile).

[guwirth]

Hello @cmorve-te,

thanks for your feedback!

Our Wiki page describing how to use paths in report files is here: https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Troubleshooting-Reports

• Make sure that your source files are read (indexed). A item in a report must always point to a indexed file.
• Relative paths in report files are always relative to the project base directory. Start relative paths always with .\ on Windows or ./ on Linux.
• The project base directory is normally the directory where you start your analysis and where the sonar-project.properties file is located. With sonar.projectBaseDir you can specify an Alternative analysis directory.

Working:

<?xml version="1.0" encoding="UTF-8"?>
<results>
    <error file=".\src\example.cpp" ... />
</results>

Question is if you are using double dot how should the sensor resolve the absolute path and map it to an indexed file?

Fail:

<?xml version="1.0" encoding="UTF-8"?>
<results>
    <error file="..\src\example.cpp" ... />
</results>

Regards,

[guwirth]

https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/FilenameUtils.html#normalize(java.lang.String,boolean)

/foo//               -->   /foo/
 /foo/./              -->   /foo/
 /foo/../bar          -->   /bar
 /foo/../bar/         -->   /bar/
 /foo/../bar/../baz   -->   /baz
 //foo//./bar         -->   /foo/bar
 /../                 -->   null
 ../foo               -->   null
 foo/bar/..           -->   foo/
 foo/../../bar        -->   null
 foo/../bar           -->   bar
 //server/foo/../bar  -->   //server/bar
 //server/../bar      -->   null
 C:\foo\..\bar        -->   C:\bar
 C:\..\bar            -->   null
 ~/foo/../bar/        -->   ~/bar/
 ~/../bar             -->   null

One possibility could be to add ".\" in case this is missing in a relative path?

1) "..\src\example.cpp"
2) ".\..\src\example.cpp"
3) normalize(".\..\src\example.cpp") => ".\src\example.cpp"

@cmorve-te But still the question why you are using relative path with double dot, and what do you expect is the root path the relative path should be resolved to?

[cmorve-te]

But still the question why you are using relative path with double dot, and what do you expect is the root path the relative path should be resolved to?

Actually, I'm not! I still have to find out what's going on exactly, but this happens during the linking step when using LTO when you have some dependencies built under build_dir1, and the main program under build_dir2. What's worse, the path is not even correct, it mixes up the build directory with the source directory.
Everything was built with absolute paths, but something in the LTO process ends up using those relative paths in the diagnostics output.

For the gcc warnings I'm looking at, I would just want them to be ignored instead of added with no location (i.e. file).

[guwirth]

For the gcc warnings I'm looking at, I would just want them to be ignored instead of added with no location (i.e. file).

@cmorve-te Have to verify this. Think it's possible to forward issues to SQ without file and/or line. But in this case I agree it's not a "global issue" it should be handled like "unkown file".

...GCC ... when using LTO

I'm not familiar with GCC but on the fly I found this: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
Maybe -no-canonical-prefixes and/or --sysroot=dir helps?

[guwirth]

Hi @cmorve-te,

you can test with #2747 if this is improving your result. You can download the JAR files from here:
https://github.com/SonarOpenCommunity/sonar-cxx/actions/runs/10789744787/artifacts/1913366510

Regards,

[cmorve-te]

FWIW my case comes from the dependency being built with -fdebug-prefix-map=old= (actually -ffile-prefix-map=old=). The path information is lost, and in the LTO stage it tries to guess it (and fails).