Code analysis reports
A discussion between me and Danij, spurred on by an analysis that he posted led me to perform an analysis of the doomsday codebase using Clang-Analyzer.
The result of running Clang-Analyzer is an interactive and detailed HTML report.
I have published this report on my website and will do so for future analyses.
As these take a long time to run (1 hour or more), they will likely only be performed at release points regardless of who produces them.
You are welcome to look in to and fix anything you should wish, though you should note that clang-analyzer does not know about things such as methods that halt execution or throw exceptions, and will assume that execution will continue
after they are called, so some null pointer dereference warnings should have extra scrutiny paid to them.
In summary, the largest portion of warnings comes from dead assignment -- e.g. a value is assigned to a field, and the field is never read thereafter.
Clang is aware of the scope of fields when doing analysis, and will not generate such warnings if the field being assigned to belongs to something else,
or is a pointer/reference/overloaded assignment operator.
A small portion of these are located in third party dependencies -- mainly the third-party zip library included with the Open Asset Import Library. I will look in to excluding these in future builds.
If you have any questions, feel free to ask me.
The result of running Clang-Analyzer is an interactive and detailed HTML report.
I have published this report on my website and will do so for future analyses.
As these take a long time to run (1 hour or more), they will likely only be performed at release points regardless of who produces them.
You are welcome to look in to and fix anything you should wish, though you should note that clang-analyzer does not know about things such as methods that halt execution or throw exceptions, and will assume that execution will continue
after they are called, so some null pointer dereference warnings should have extra scrutiny paid to them.
In summary, the largest portion of warnings comes from dead assignment -- e.g. a value is assigned to a field, and the field is never read thereafter.
Clang is aware of the scope of fields when doing analysis, and will not generate such warnings if the field being assigned to belongs to something else,
or is a pointer/reference/overloaded assignment operator.
A small portion of these are located in third party dependencies -- mainly the third-party zip library included with the Open Asset Import Library. I will look in to excluding these in future builds.
If you have any questions, feel free to ask me.