Fixed typos and citations issues. (#381)

* Fixed typos and citations issues in the related work chapter.

Fixed several typos and citation issues such as wrong citation and
missing citation.

* Fixed typo and grammar error.

spec/bounds_safety/related-work.tex

@@ -193,7 +193,7 @@ \section{Runtime-based approaches}
 
 Light-weight Bounds Checking \cite{Hasabnis2012} is an optimized implementation of bound
 checking that uses ``red zones''.
-it focuses solely on bounds checking.  It uses a bitmap to track
+It focuses solely on bounds checking.  It uses a bitmap to track
 which bytes in memory correspond to allocated objects and which do not.
 It uses a two-level table to avoid allocating a table equal to 1/8 of the
 address space.  It optimizes memory reads by filling red zones with special
@@ -253,7 +253,8 @@ \section{Runtime-based approaches}
 the splay tree and  to avoid having to create entries for single-element arrays 
 or scalar objects in the splay tree.
 
-Baggy Bounds Checking \cite{Akritidis2008} provides a faster implementation
+Baggy Bounds Checking \cite{Akritidis:2009:BBC:1855768.1855772}
+provides a faster implementation
 of the side data structure in Jones and Kelly.  The implementation 
 calculates the bounds for any pointer in constant-time.   To achieve this,
 the implementation constrains object sizes to be powers of 2.  It also reserves 
@@ -280,7 +281,7 @@ \section{Runtime-based approaches}
 increases average program execution time by 56\% and checking only writes 
 increases average execution time by 13\%. In \cite{Duck2017}, the authors extended 
 Low Fat Pointers to also provide stack bounds protection, incurring a 17\% overhead when checking 
-only writes. Low Fat Pointers for heap \cite{Duck2016} and stack {Duck2017} bounds protection were
+only writes. Low Fat Pointers for heap \cite{Duck2016} and stack \cite{Duck2017} bounds protection were
 integrated and released as an open source research prototype available at 
 \url{https://github.com/GJDuck/LowFat}.
 
@@ -345,7 +346,7 @@ \section{Security mitigations}
 a arbitrary program.  There are other ways to manipulate program state to
 change control-flow, such as changing the target of an indirect function call.  
 This can be done by 
-ovewriting a function pointer or the virtual table of an object.
+overwriting a function pointer or the virtual table of an object.
 \item Data modification: an attacker may be able to write data to a process, causing the process to take an incorrect action on behalf of an attacker.
 \item  Data disclosure: an attacker may be able to read data from a process 
 and obtain data, including data that is meant to be confidential.  
@@ -363,12 +364,12 @@ \section{Security mitigations}
 data disclosure attacks, which the other approaches do not.
 Chen {\it et al.} \cite{Chen2005} show that data modification
 attacks that do not alter control-flow pose a serious long-term threat.
-The Heartbleed attack on OpenSSL illustrates the damage that is
-possible from even data disclosure attacks.
+The Heartbleed attack on OpenSSL~\cite{Heartbleed} illustrates the damage that
+is possible from even data disclosure attacks.
 
 Checked C addresses the fundamental problem, which is incorrect programs
 with undetected errors. Checked C enhances existing security mitigations by
-providing protection against data modification and data modification attacks.
+providing protection against data modification and data disclosure attacks.
 ASLR, DEP, CFI, and stack canaries can be 
 defeated by determined attackers using data modification and data disclosure
 attacks.  Shadow stacks do not protect stack-allocated buffers or arrays, 

spec/bounds_safety/sources.bib

@@ -2296,4 +2296,8 @@ @inproceedings{Zhang2015
  address = {New York, NY, USA},
 } 
 
-
+@misc{Heartbleed,
+    title = {The Heartbleed Bug},
+    year = 2014,
+    note = "\url{http://heartbleed.com}",
+}

spec/bounds_safety/void-ptr-replacements.tex

@@ -118,10 +118,10 @@ \section{Generic functions}
 to some type \var{T}.  At calls to the function, pointers to \var{T} are cast
 implicitly to \uncheckedptrvoid{} or back from \uncheckedptrvoid{}.  
 Sometimes the function is re-used by casting integers to \uncheckedptrvoid{} pointers.
-We want to able to check these uses and ensure they do not cause type confusion.
+We want to be able to check these uses and ensure they do not cause type confusion.
 
 We want there to be a single copy of a generic function so that programmers
-retain low-level control and updated code is binary ompatible with existing code.  
+retain low-level control and updated code is binary compatible with existing code.
 This means that the code cloning as is done in C++ templates cannot be used.  
 We instead require that a uniform representation for generic data be used.
 Generic data must either be treated as an incomplete type (with no assumption