In general, PhASAR supports two kinds of analyses:
Generally useful analyses such as constant analysis and alias analysis (and in future points-to analysis)
Analyses reporting undesired dataflows
While analyses of the first kind typically run as helper analysis for a different client analysis, the latter kind oftentimes runs in whole-program analysis (WPA) mode or module-wise analysis (MWA) mode and aims to find bugs of vulnerabilities in the software under analysis.
Currently, the only way in reporting analysis results is by either specializing the emitTextReport() function on the analysis problem or by relying on the raw SolverResults. While this is mostly sufficient for helper analyses, reporting analysis lack a common way of reporting results in a generic way.
So, propose the following: The analysis problem permits an event-based reporting solution, that (for example via callbacks) allows to report findings in a generic way. This also adds the benefit of on-the-fly reporting: With the emitTextReport and SolverResults strategy all analysis results are only available once the whole analysis run has completed. Intermediate results are not supported. However, in a bigger system with other components (or users) waiting for analysis results it may be beneficial to report (intermediate) results as they arrive.
Prerequisites
issue x
Out Of Scope
A isn't part of this
Acceptance Criteria
The following acceptance criteria are defined regarding the result of this story:
Clarify what the final result should be, not how to accomplish it.
[ ] The IFDSTabulationProblem and IDETabultation problem provide an opt-in solution for generic reporting of analysis findings
[ ] The results reporting allows for reporting intermediate results
Story
In general, PhASAR supports two kinds of analyses:
While analyses of the first kind typically run as helper analysis for a different client analysis, the latter kind oftentimes runs in whole-program analysis (WPA) mode or module-wise analysis (MWA) mode and aims to find bugs of vulnerabilities in the software under analysis.
Currently, the only way in reporting analysis results is by either specializing the emitTextReport() function on the analysis problem or by relying on the raw SolverResults. While this is mostly sufficient for helper analyses, reporting analysis lack a common way of reporting results in a generic way.
So, propose the following: The analysis problem permits an event-based reporting solution, that (for example via callbacks) allows to report findings in a generic way. This also adds the benefit of on-the-fly reporting: With the emitTextReport and SolverResults strategy all analysis results are only available once the whole analysis run has completed. Intermediate results are not supported. However, in a bigger system with other components (or users) waiting for analysis results it may be beneficial to report (intermediate) results as they arrive.
Prerequisites
Out Of Scope
Acceptance Criteria
The following acceptance criteria are defined regarding the result of this story: Clarify what the final result should be, not how to accomplish it.
Related Stories
Follow-up Stories