Difference between revisions of "HOWTO-Static Analysis Tools"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Page created)
 
(Fix formatting and grammar)
Line 6: Line 6:
Our major tool, located at [https://scan.coverity.com/projects/scummvm?tab=overview this URL].
Our major tool, located at [https://scan.coverity.com/projects/scummvm?tab=overview this URL].


To get access, you must be a member of ScummVM Team and issue a request on that page. Ping [[Users::Sev sev]] for getting your request approved.
To get access, you must be a member of ScummVM Team and issue a request on that page. Ping [[User:Sev|sev]] for getting your request approved.


Some guidances:
Some guidances:


# The analysis runs every Monday night EU time, and completes at around 3am. Ping [[Users::Sev sev]] if you want to have it re-analysed. But due to the size of our project, the limitation is to run analysis every 24 hours.
# The analysis runs every Monday night EU time and completes at around 3 am. Ping [[User:Sev|sev]] if you want to have it re-analysed. But due to the size of our project, the limitation is to run an analysis every 24 hours.
# Use "Components -> All in Project" for viewing defect in your engine or subsystem (use hamburger menu for navigation)
# Use "Components -> All in Project" for viewing defects in your engine or subsystem (use the hamburger menu for navigation)
# Once you fixed a bug, specify it classification, severity, Action should be "Fixed, tested & documented" and assign owner to yourself (autocompletion works there)
# Once you have fixed a bug, specify its classification and severity. Action should be "Fixed, tested & documented" and assign an owner to yourself (autocompletion works there)
# Address all possible issues. If you clearly see that it is a false positive, which is rare but happens, feel free to specify "False Positive", "Ignore" but still assign to yourself
# Address all possible issues. If you clearly see that it is a false positive, which is rare but happens, feel free to specify "False Positive" or "Ignore" but still assign it to yourself
# Be super vigilant regarding High Impact issues such as memory leaks, use-after-free and other things
# Be super vigilant regarding High Impact issues such as memory leaks, use-after-free and other things
# Regarding TAINTED SCALAR issues, we have great tons of those and we used to dismiss them. Yes, it may lead to an issue when a manually crafted game data might lead to a crash or some memory overflow exploits, but once we have data integrity subsystem implemented, those will be eliminated.
# Regarding TAINTED SCALAR issues, we have great tons of those and we used to dismiss them. Yes, it may lead to an issue when manually crafted game data might lead to a crash or some memory overflow exploits, but once we have the data integrity subsystem implemented, those will be eliminated.




Line 21: Line 21:
We use it on GitHub.
We use it on GitHub.


In [[User::Sev sev's]] opinion it is mostly useless. It is an AI-based tool that seemingly runs by pattern matching. As a result, it produces tons of some strange complaints about somebody's standards of code formatting etc.
In [[User:Sev | sev's]] opinion it is mostly useless. It is an AI-based tool that seemingly runs by pattern matching. As a result, it produces tons of strange complaints about somebody's standards of code formatting etc.


Use at your discretion.
Use at your discretion.

Revision as of 11:42, 22 July 2022

We use Static Analysis tools at ScummVM.

Here is some guidance on their usage

Coverity

Our major tool, located at this URL.

To get access, you must be a member of ScummVM Team and issue a request on that page. Ping sev for getting your request approved.

Some guidances:

  1. The analysis runs every Monday night EU time and completes at around 3 am. Ping sev if you want to have it re-analysed. But due to the size of our project, the limitation is to run an analysis every 24 hours.
  2. Use "Components -> All in Project" for viewing defects in your engine or subsystem (use the hamburger menu for navigation)
  3. Once you have fixed a bug, specify its classification and severity. Action should be "Fixed, tested & documented" and assign an owner to yourself (autocompletion works there)
  4. Address all possible issues. If you clearly see that it is a false positive, which is rare but happens, feel free to specify "False Positive" or "Ignore" but still assign it to yourself
  5. Be super vigilant regarding High Impact issues such as memory leaks, use-after-free and other things
  6. Regarding TAINTED SCALAR issues, we have great tons of those and we used to dismiss them. Yes, it may lead to an issue when manually crafted game data might lead to a crash or some memory overflow exploits, but once we have the data integrity subsystem implemented, those will be eliminated.


Codacy

We use it on GitHub.

In sev's opinion it is mostly useless. It is an AI-based tool that seemingly runs by pattern matching. As a result, it produces tons of strange complaints about somebody's standards of code formatting etc.

Use at your discretion.


cppcheck

You may run it manually. Some team members periodically run it and fix the most outstanding issues.