update readme

CodeQL_Queries/cpp/Chrome/README.md

@@ -12,11 +12,11 @@ The libraries in this repository are organized as follows:
 
 ### `commons.qll`:
 
-Mostly contain general enchancement to the standard QL library and some Chromium specific, but still general material. For example, because the operators `->` and `=` are often overloaded in Chrome, this somehow upsets the usual `getQualifier` and `Assignment` in QL, so two general methods, `getQualifier` and `GeneralAssignment` are implemented to take these into account. Another useful predicates are `constructionCall` and `polyConstructionCall`, which identify all the constructor calls, as well as constructions via `make_unique` and `MakeRefCounted` (the former works fine in code search, but not the later, but neither will work on vanilla QL (you just ended inside the standard library))
+Mostly contain general enchancements to the standard QL library and some Chromium specific, but still general material. For example, because the operators `->` and `=` are often overloaded in Chrome, this somehow upsets the usual `getQualifier` and `Assignment` in QL, so two general methods, `getQualifier` and `GeneralAssignment` are implemented to take these into account. Other useful predicates are `constructionCall` and `polyConstructionCall`, which identify all the constructor calls, as well as constructions via `make_unique` and `MakeRefCounted`. `make_unique` works fine in code search, but not `MakeRefCounted`. Neither will work on vanilla QL, where you just end inside the standard library.
 
 ### `collections.qll`:
 
-Generally deals with `std::map`, `std::vector` etc. I use some heuristics there because there are just too many different types of containers and it is likely to miss out some if I add them manually. The library provides methods that get the component types of a container and also function calls that set/reset components in a container. A set/reset method call (e.g. push_back/erase/clear etc.) are useful as they are needed to identify when raw pointers might get remove and when managed pointers may get reset (which will cause the underlying object to be deleted and may cause a UaF somewhere else) Many bugs are actually related to pointers/managed pointers stored in containers.
+Generally deals with `std::map`, `std::vector` etc. I use some heuristics there because there are just too many different types of containers and it is likely to miss some if I add them manually. The library provides methods that get the component types of a container and also function calls that set/reset components in a container. A set/reset method call (e.g. push_back/erase/clear etc.) are useful as they are needed to identify when raw pointers might get removed and when managed pointers may get reset (which will cause the underlying object to be deleted and may cause a UaF somewhere else). Many bugs are actually related to pointers/managed pointers stored in containers.
 
 ### `callbacks.qll`:
 
@@ -46,7 +46,7 @@ Only used by `callbacks.qll` to track the types stored in callbacks.
 
 ### `bindings.qll`
 
-Use for modelling mojom interface.
+Used for modelling the Mojo interface.
 
 ## `pointers`: 
 
@@ -56,8 +56,8 @@ QL libraries for managed and raw pointers.
 
 ### `lifetime_management.qll`:
 
-QL library that models various clean up logic in Chrome. I haven't got round to implement too much code there yet.
+QL library that models various clean up logic in Chrome. I haven't got round to implementing too much code there yet.
 
 `obj_lifetime.qll`:
 
-Mostly contain classes that are long living, e.g. BrowserContext, Singleton and the objects that they manage. Mostly use to exclude raw pointer results as these are not likely to be destroyed.
+Mostly contains classes that are long living, e.g. BrowserContext, Singleton and the objects that they manage. Mostly used to exclude raw pointer results as these are not likely to be destroyed.

CodeQL_Queries/cpp/Chrome/queries/README.md

@@ -1,30 +1,30 @@
 # Example queries
 
-The queries in this directory are more of an example of how to use the CodeQL libraries in the repository, rather than concrete queries use for finding bugs. Many of these requires tweaking of some filters to restrict the results to some subset of the Chromium codebase.
+The queries in this directory are more of an example of how to use the CodeQL libraries in the repository, rather than concrete queries used for finding bugs. Many of these require tweaking filters to restrict the results to some subset of the Chromium codebase.
 
 Here is an overview of what they do:
 
 ## Callback tracking
 
-These queries uses the `callbacks.qll` library and are useful in checking raw pointers that are stored in a particular callback. The library `callbacks.qll` divides callbacks into the following types: `CallbackFieldSink`, `CallbackPostTaskSink`, `CallbackRunSink`, `CallbackInterfacePtrSink` that allows further specification of callback types. In general, it is recommended to run this query without restriction first, and use the result as a look up table during manual inspection, instead of running the query every time with different restrictions to the sink, as the former will be more efficient.
+These queries use the `callbacks.qll` library and are useful in checking raw pointers that are stored in a particular callback. The library `callbacks.qll` divides callbacks into the following types: `CallbackFieldSink`, `CallbackPostTaskSink`, `CallbackRunSink`, `CallbackInterfacePtrSink` that allows further specification of callback types. In general, it is recommended to run this query without restriction first, and use the result as a lookup table during manual inspection, instead of running the query every time with different restrictions to the sink, as the former will be more efficient.
 
 ### `callback_unretained.ql`
 
-Use to identify the pointer types that are stored inside a callback. This is a very useful query for investigation as callbacks often contain other callbacks and it can take sometime to figure out what is store in them.
+Used to identify the pointer types that are stored inside a callback. This is a very useful query for investigation as callbacks often contain other callbacks and it can take some time to figure out what is stored in them.
 
 ### `callback_unretained_field.ql`
 
-Like `callback_unretained.ql`, but specifically look for callback fields and output the specific field associated with the callback. This is often useful as callback fields can be hard to track manually.
+Like `callback_unretained.ql`, but specifically looks for callback fields and outputs the specific field associated with the callback. This is often useful as callback fields can be hard to track manually.
 
 ## Pointer cleanup
 
-These queries are used for looking up the cleanup pattern of raw pointer fields. This is generally achieved by matching types of the field with cleanup operations performed on fields of the same type, rather than tracking the precise movement of the field itself. This is a compromised that has to be made in order to reduce the complexity of the queries and make them feasible, both in terms of the manual effort involved in writing the libraries and the running time of the queries. In practice, this compromised works mostly ok.
+These queries are used for looking up the cleanup pattern of raw pointer fields. This is generally achieved by matching types of the field with cleanup operations performed on fields of the same type, rather than tracking the precise movement of the field itself. This is a compromise that has to be made in order to reduce the complexity of the queries and make them feasible, both in terms of the manual effort involved in writing the libraries and the running time of the queries. In practice, this compromise works out mostly ok.
 
 ### `no_cleanup.ql`
 
-A query that is used to identify raw pointer fields that does not get set to nullptr, or gets erase from container (clean up), while removing some cases that are less likely to be dangerous.
+A query that is used to identify raw pointer fields that does not get set to nullptr, or gets erased from containers (clean up), while removing some cases that are less likely to be dangerous.
 
 ### `non_trivial_cleanup.ql`
 
-This is similar to no_cleanup.ql, but instead looks for raw pointers that does get clean up, but the clean up is not called (transitively) from the destructor of the pointer type. The idea is that there may be ways to destroy the pointer without removing the field (as the destructor does not do the clean up).
+This is similar to no_cleanup.ql, but instead looks for raw pointers that do get cleaned up, but the clean up is not called (transitively) from the destructor of the pointer type. The idea is that there may be ways to destroy the pointer without removing the field (as the destructor does not do the clean up).