102 lines
2.2 KiB
Org Mode
102 lines
2.2 KiB
Org Mode
#+TITLE: Program Analysis
|
|
#+Author: Adam Mohammed
|
|
|
|
|
|
* Program Analysis tools
|
|
|
|
Generally program analysis tools come in two forms, static and
|
|
dynamic. Each has tradeoffs that we need to understand, especially
|
|
when we start to build these tools.
|
|
|
|
It's important to understand what each analysis tool is good for,
|
|
knowing what it's strong at detecting, as well as knowing what they
|
|
are not good for and where they struggle.
|
|
|
|
** Examples of Static Analysis
|
|
RuboCop
|
|
Gofmt
|
|
Rufo
|
|
*** Good
|
|
- Detecting syntax errors
|
|
- Detecting simple semantic errors
|
|
- Detecting style violations
|
|
- Detecting code convention violations
|
|
|
|
*** Bad
|
|
- Prone to false positives and false negatives
|
|
- Requires access to source code, including libraries
|
|
- Does not account for runtime environment
|
|
|
|
|
|
** Examples of Dynamic Analysis
|
|
Profilers
|
|
- ruby-prof
|
|
|
|
Memory leak detection
|
|
- Valgrind
|
|
|
|
Data Races
|
|
- Go race detector
|
|
|
|
|
|
|
|
|
|
*** Good
|
|
- Detect bugs that only can occur at runtime
|
|
- Capable of measuring things inlfuenced by factors outside of source code
|
|
- e.g. Network latency, External errors, etc
|
|
- Generally less false positives and false negatives because error
|
|
cases must occur to be detected
|
|
|
|
*** Bad
|
|
- Requires actually violating edge cases to report them
|
|
- Often incurs performance penalty to instrument live code
|
|
- True positives can be missed for code paths that are not exercised often.
|
|
|
|
|
|
** Problem we're actually facing
|
|
|
|
- Monolith is large and old
|
|
- OAS is used as the source of truth to generate clients and documentation that customers rely on
|
|
- Monolith and OAS don't agree most of the time
|
|
|
|
|
|
** Solutions we're trying
|
|
|
|
https://github.com/equinixmetal/api-spec-inspector - form of SA
|
|
|
|
|
|
** Back to basics
|
|
|
|
How do programming languages do their job?
|
|
|
|
Source code -> interpreted -> output
|
|
|
|
If you're in a compiled languages
|
|
|
|
source code -> compiled -> executable -> output
|
|
|
|
|
|
We treat "interpreters" and "compilers" as black boxes for the most part.
|
|
|
|
Let's pull back the curtains on these things though:
|
|
|
|
** How does code get interpreted?
|
|
|
|
1. Show ruby-parse
|
|
|
|
2. Talk about AST
|
|
|
|
** Utilizing the AST
|
|
|
|
ex 01-03_
|
|
|
|
** Problem areas for test parsing
|
|
|
|
ex 04 vrf params
|
|
|
|
|
|
** Rubocop Examples
|
|
|
|
https://github.com/rubocop/rubocop/blob/02c32b4cf3801f9cf4cca4b3f1f4288aaee2ad5c/lib/rubocop/cop/lint/useless_setter_call.rb
|