Is there really no way to see C code issues in Pro*C code? Over 80% of our C code is Pro*C (in source files we name *.sc). It would be great if it could scan the C code, even if it ignored the embedded SQL.
I’m evaluating SonarQube for our project, and this could really prevent it being useful for us.
Hi @pderr ,
no, there is no way to analyze Pro*C code and we currently don’t have a plan to support it. The only way I see is to separate the Pro*C code from the C one and analyze the C code.
Hello @pderr,
As Massimo said, we do not directly support Pro*C. However, there is a workaround that might be working nicely for you.
Since Pro*C relies on a preprocessor to generate some C code that is then compiled, one option that you could have would be to scan not only your source code, but also this generated code. This comes with a few caveats:
- If an issue is reported in the generated code, you would have to manually infer where in the original source code lies this issue
- Since the generated code is usually not under source control, you may not benefit from all the features related to tracking source control changes that we normally provide.
- Since the code is generated, it may contain issues that are not relevant. But from what I remember from Pro*C, the generated code is relatively readable by a human being, so it should not be too bad.
If these limitation can work for you, the main thing to have it working is to make sure that the place where those files are generated is part of the sonar.sources configuration property. They should already be mentioned in the build-wrapper-dump.json file.
Please let us know what you decided to do, and contact us if you have difficulties.
Thank you,
1 Like
Roughly one and a half year have passed since… just asking, if there’s an update on this stance…
In our project, we just scan the results of oracle-preprocessor, and the number of “false” positives is really high… the oracle preprocessor adds lots of typedefs, C-style arrays, non-const global vars, etc.
Hi @avl, and welcome to our community.
The current traction we observe on Pro*C does not allow us to shortlist its support in our current plans.
We keep recording traction (as I just did for your ask), and if the situation evolves, it adjust our priorities accordingly.
That’s entirely economically understandable…
To those who found this thread from a google search (as I did):
If you have oracle’s pre-processor in the build-process (for c/c++ files embedding sql statements) and want these sources to be checked by sonarqube, please speak up here, as well. It just won’t happen otherwise.
Some more hints:
The scanner for the C/C++/… family only runs on the actually supported platforms (linux, windows, mac, and a forth one that I’ve forgotten), because it uses native code. Some other language-scanners for sonarqube are running fully in java, and thus also on some unsupported systems like solaris, where you just need to replace the jre).
If your sources and build-process are really on a non-supported system, and the build-process cannot be transferred to a system supported by sonar-scanner, then you need to look for “compiler database”, which is a rather simple json-format text file which contains a structure of { path, source-filename and the exact compiler-invocation } for each compiled source module. Most build-tools have some switches to have them print out the actual compiler calls and eventual directory changes. I wrote a script to convert the build-log into a “compiler database”, myself.
Additionally, the host to run the scanner will try to call the compiler with certain special arguments:
g++ -x c++ -v -dM -E -
sending it immediate EOF on stdin, and from output it will extract the “__cplusplus”-define.
A script named “g++” with content
echo “#define __cplusplus 201703L”
(the value here is that from the compiler on solaris) will do, if (just for the scanner-run) it is in the $PATH before any real g++.
1 Like