philosophy.md : Describe inconclusive messages #2841
Conversation
Inspired by #2839 inconclusive messages are added to this document.
| @@ -22,6 +22,9 @@ Reporting issues in Trac: | |||
| - If you see a false negative; report that as an enhancement. | |||
| - If you see a false positive; report that as a defect. | |||
|
|
|||
| ### Inconclusive messages | |||
|
|
|||
| Inconclusive messages will be created if cppcheck cannot be sure there is an issue to warn but 50-50 probability. User shall enable inconclusive messages if they are willing to spend substantially more time on message verification in order to find more issues within a high false positive rate. | |||
There was a problem hiding this comment.
so this seems to indicate that ~50% noise ratio would be acceptable.. no matter if it's about something stylistic or UB. so if we get 70%-80% then its too much.
I think this document should be useful for contributors. can it also say something that if a warning will be inconclusive in certain cases then it would be good to use a separate id in those cases ; that will make it easier to check noise ratio etc in daca@home.
There was a problem hiding this comment.
I would like that it said something for developers.. the inconclusive category is not meant for unfinished checks etc. if false positives can be avoided with further analysis then inconclusive checks must perform further analysis. This is for situations when the checker can't know.
There was a problem hiding this comment.
Should it therefore refer to settings.experimental ?
Add hint for developers
amai2012
changed the title
Inspired by #2839 inconclusive messages are added to this document.