Update intro-to-clr.md

diff --git a/Documentation/intro-to-clr.md b/Documentation/intro-to-clr.md
index d17d890..03df046 100644 (file)
--- a/Documentation/intro-to-clr.md
+++ b/Documentation/intro-to-clr.md
@@ -109,7 +109,7 @@ In addition, there is another important ramification of managed code that may no
 
 The result of this is that unmanaged interfaces are almost always _wrapped_ before being exposed to managed code developers.  For example, when accessing files, you don't use the Win32 CreateFile functions provided by the operating system, but rather the managed System.IO.File class that wraps this functionality.  It is in fact extremely rare that unmanaged functionality is exposed to users directly. 
 
-While this wrapping may seem to be "bad" in some way (more code that does not seem do much), it is in fact good because it actually adds quite a bit of value.  Remember it was always _possible_ to expose the unmanaged interfaces directly; we _chose_ to wrap the functionality. Why?  Because the overarching goal of the runtime is to **make programming easy** , and typically the unmanaged functions are not easy enough.  Most often, unmanaged interfaces are _not_ designed with ease of use in mind, but rather are tuned for completeness. Anyone looking at the arguments to CreateFile or CreateProcess would be hard pressed to characterize them as "easy." Luckily, the functionality gets a "facelift" when it enters the managed world, and while this makeover is often very "low tech" (requiring nothing more complex than renaming, simplification, and organizing the functionality), it is also profoundly useful.  One of the very important documents created for the CLR is the [Framework Design Guidelines](fx-design-guidelines). This 800+ page document details best practices in making new managed class libraries. 
+While this wrapping may seem to be "bad" in some way (more code that does not seem do much), it is in fact good because it actually adds quite a bit of value.  Remember it was always _possible_ to expose the unmanaged interfaces directly; we _chose_ to wrap the functionality. Why?  Because the overarching goal of the runtime is to **make programming easy** , and typically the unmanaged functions are not easy enough.  Most often, unmanaged interfaces are _not_ designed with ease of use in mind, but rather are tuned for completeness. Anyone looking at the arguments to CreateFile or CreateProcess would be hard pressed to characterize them as "easy." Luckily, the functionality gets a "facelift" when it enters the managed world, and while this makeover is often very "low tech" (requiring nothing more complex than renaming, simplification, and organizing the functionality), it is also profoundly useful.  One of the very important documents created for the CLR is the [Framework Design Guidelines][fx-design-guidelines]. This 800+ page document details best practices in making new managed class libraries. 
 
 Thus, we have now seen that managed code (which is intimately involved with the CLR) differs from unmanaged code in two important ways:
 
@@ -133,7 +133,7 @@ While the [common intermediate language][cil-spec] (CIL) _does_ have operators t
 1. Field-fetch operators (LDFLD, STFLD, LDFLDA) that fetch (read), set, and take the address of a field by name.  
 2. Array-fetch operators (LDELEM, STELEM, LDELEMA) that fetch, set, and take the address of an array element by index. All arrays include a tag specifying their length. This facilitates an automatic bounds check before each access. 
 
-By using these operators instead of the lower-level (and unsafe) _memory-fetch_ operators in user code, as well as avoiding other unsafe [CIL](cil-spec) operators (e.g., those that allow you to jump to arbitrary, and thus possibly bad locations) one could imagine building a system that is memory-safe, but nothing more. The CLR does not do this, however. Instead the CLR enforces a stronger invariant: type safety. 
+By using these operators instead of the lower-level (and unsafe) _memory-fetch_ operators in user code, as well as avoiding other unsafe [CIL][cil-spec] operators (e.g., those that allow you to jump to arbitrary, and thus possibly bad locations) one could imagine building a system that is memory-safe, but nothing more. The CLR does not do this, however. Instead the CLR enforces a stronger invariant: type safety. 
 
 For type safety, conceptually each memory allocation is associated with a type.  All operators that act on memory locations are also conceptually tagged with the type that for which they are valid. Type safety then requires that memory tagged with a particular type can only undergo operations allowed for that type.  Not only does this ensure memory safety (no dangling pointers), it also allows additional guarantees for each individual type.