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.
gccwas 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
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
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.