message: Fixes types in README.md
diff: @@ -78,9 +78,9 @@ Example of json used to power radeco:
  ```
  Explanation of the above fields:
  -* `bin_name`: Relative path to the binary to be analyzed
  +* `bin_name`: Relative path to the binary to be analysed
  * `esil`: radeco allows users to load raw esil [WIP]
  -* `addr`: Address from where the instructions to be analyzed must be loaded.
  +* `addr`: Address from where the instructions to be analysed must be loaded.
  This field can take an address such as `0xbadcode` or any symbols identified
  by r2 such as `sym.main`
  * `name`: Name of the analysis. This name is used to name the generated output
  @@ -90,7 +90,7 @@ Explanation of the above fields:
  text files for esil and instructions.
  * `stages`: list of stages in the radeco pipeline. Output from one stage is
  automatically fed as input for the next stage of the analysis. More
  - infomration about the pipeline is descibed in the pipeline section of this
  + information about the pipeline is described in the pipeline section of this
  document.
  * `verbose`: Prints out current stage and other debug information.
  @@ -100,7 +100,7 @@ radeco describes the various stages of the analysis in terms of a pipeline.
  The output of one stage of the pipeline is directly fed into the next stage.
  For this reason, the user must ensure that the output of the previous stage of
  the pipeline is compatible with the stage directly after it. Here we briefly
  -descibe the stages of the pipeline as it is now. Note that these are very
  +describe the stages of the pipeline as it is now. Note that these are very
  likely to change in the future as more analysis are currently being added to
  expand radeco's arsenal.
  @@ -112,12 +112,12 @@ expand radeco's arsenal.
  ssa representation and is never used in any of the analysis. This forms
  the base of the ssa form and can help debug the ssa construction when
  needed. Also, it is slightly more readable that the SSA graph. This stage
  - requires that the Pipeout is initialized with the esil instructions to be
  + requires that the Pipeout is initialised with the esil instructions to be
  used by this stage.
  3. __Build CFG__: radeco takes the IR generated from the previous stage and breaks
  it up into Basic Blocks and constructs a control flow graph of the same.
  This stage is required for the SSA construction which is usually the next
  - phase. This phase can be helpful to analyze the control flow structuring
  + phase. This phase can be helpful to analyse the control flow structuring
  the program without paying much attention to the instructions actually
  present inside the Basic Blocks.
  4. __Build SSA__: The CFG generated by radeco is used to construct the Static
  @@ -125,13 +125,13 @@ expand radeco's arsenal.
  Representation and is used for all subsequent analysis. The output for this
  stage is a dot file which can be used with a graphing utility like graphviz
  to generate a human readable SSA graph. All analysis, Dead Code Elimination
  - and Veriy expect SSA to be in the Pipeout.
  + and Verify expect SSA to be in the Pipeout.
  5. __Constant Propagation__: radeco currently supports constant propagation to
  propagate constants and generate a better SSA graph. It is recommended to
  - run Dead Code Elimination after this step to ensure all the unerachable
  + run Dead Code Elimination after this step to ensure all the unreachable
  nodes are removed and cleaned up.
  6. __Dead Code Elimination__: This pass expects the previous stage of the pipeline
  - to output an SSA. Provided with an SSA, DCE cleans up all the ndoes that
  + to output an SSA. Provided with an SSA, DCE cleans up all the nodes that
  are detected to be unreachable or are removed.
  7. __Verify__: This pass is essentially to ensure the integrity of the SSA form.
  Therefore it expects SSA to be the output of the previous stage of the
  