Is it wise to use Clang for personal code analysis in a project that builds with gcc?

Question

I started to work on several C projects that are building using gcc. I believe this choice was made for several reasons:

• Had to cross-compile for arm very early on (I think).
• Performance is the first and foremost spec.
• gcc was and is still the easy first choice.

I have no reason to contest that choice and I am not in a position to do so anyway.

The codebase of any single project is relatively small. Every project builds with a relatively clean Makefile (currently being refreshed), gcc -Wall -Wextra doesn't complain nearly at all and some minimal testing is done. There is no automated static analysis or code formatting being done and the code is syntaxically not consistent, although it is very readable and feels thought out.

I do not want to reformat every line of code at once, I intend to do as described somewhere around this answer (especially since the context really isn't as bad): refactoring and mainly reformatting as much as possible when dealing with any topic, but sill taking topics with no code style intentions in mind. Unfortunately, I am not in a position to impose a code style or additional checks on commits, but I feel like there is a sense among my colleagues that you should respect the existing code convention when modifying a file (Although I am aware the current state of the code didn't magically happen), and a desire to write good code.

This is my first time programming in C with such a state of mind, and I'm very attracted to the various code analysis and formatting tools that clang provides.

The gist of my question is thus: could it lead to problems to follow clang hints and use clang formatting and analysis tools while building with gcc? For example, some warnings could come from an internal representation gcc does not use, or from bytecode clang would intend to generate that gcc won't.

Is there a good way to automatically pass the gcc compilation parameters (mainly the target architecture and optimization level) to clang so that the warning hints make sense?

I'll add that I am familiar with gcc and its error reporting. I am interested in getting more (relevant) warnings and errors, not just better worded and more understandable warnings. So if I cannot trust additional hints that clang can produce based on its internal representation because I build with gcc at the end of the day, then I'm not really interested in doing this.

I included a lot of context so feel free to make any remark or to answer any underlying question I could not bring out.

Answer 1

For example, some warnings could come from an internal representation gcc does not use, or from bytecode clang would intend to generate that gcc won't.

Extremely unlikely. Clang is warning you about your code, not some internal representation that it uses. All warnings should derive from something suspicious you are doing in your code, not from any implementation details of clang.

Where you might have trouble is if any of the code you are using uses non-standard C++. GCC supports a lot of extensions to C++ which won't be accepted by other compilers. If you use any of these, clang may simply refuse to compile your code. GCC has to support compiling a lot of old code, and (as I understand it) is more lenient on some points than Clang.

Answer 2

I am using both at work, gcc and clang. You will get more warnings with both compilers together, of course, and this is great. On the other hand the warnings can contradict each other.

The most annoying case I found, is when clang detects a default rule in switch and says the all values are already covered and gcc insists on having default case (documented here). But you will only see this contradiction when you setup very strict warnings on both compilers.

Subjectively, I would say that clang has got stricter warnings and you can even get more of them if you use -Weverything or even the clang analyzer (static code analyzer). But I have also had warnings that gcc discovered and were also important.

Most compiler switches have exactly the same name. The names of warning switches differ. This may be annoying if you decide to use -Wno-* options to disable warnings. You won't be able to avoid conditional compilation in make/cmake, as far as I can see, but it's not hard to solve this.

I would avoid to format code with automatic tools. It is annoying because it pollutes the blame output. And then long-running merges may become very difficult.