Fix essentially all remaining typoes

docs/i.10.1-identifiers.md

@@ -6,4 +6,4 @@ In order to make tools work well with a case-sensitive language it is important
 
 At the same time, it is important that externally visible names not conflict with one another when used from a case-insensitive programming language. As a result, all identifier comparisons shall be done internally to CLS-compliant tools using the Canonical form KC, which first transforms characters to their case-canonical representation. See CLS Rule 4, in §[I.8.5.1](i.8.5.1-valid-names.md).
 
-When a compiler for a CLS-compliant language supports interoperability with a non-CLScompliant language it must be aware that the CTS and VES perform all comparisons using codepoint (i.e., byte-by-byte) comparison. Thus, even though the CLS requires that persisted identifiers be in Canonical form C, references to non-CLS identifiers will have to be persisted using whatever encoding the non-CLS language chose to use. It is a language design issue, not covered by the CTS or the CLS, precisely how this should be handled.
+When a compiler for a CLS-compliant language supports interoperability with a non-CLS-compliant language it must be aware that the CTS and VES perform all comparisons using code-point (i.e., byte-by-byte) comparison. Thus, even though the CLS requires that persisted identifiers be in Canonical form C, references to non-CLS identifiers will have to be persisted using whatever encoding the non-CLS language chose to use. It is a language design issue, not covered by the CTS or the CLS, precisely how this should be handled.

docs/i.11-collected-common-language-specification-rules.md

@@ -40,15 +40,15 @@ The complete set of CLS rules are collected here for reference. Recall that thes
 
 **CLS Rule 19:** CLS-compliant interfaces shall not define static methods, nor shall they define fields. (§[I.8.9.4](i.8.9.4-interface-type-definition.md))
 
-**CLS Rule 20:** CLS-compliant classes, value types, and interfaces shall not require the implementation of non-CLS-compliant members. (§[I.8.9.6.4]](#todo-missing-hyperlink))
+**CLS Rule 20:** CLS-compliant classes, value types, and interfaces shall not require the implementation of non-CLS-compliant members. (§[I.8.9.6.4](i.8.9.6.4-supporting-interface-contracts.md))
 
-**CLS Rule 21:** An object constructor shall call some instance constructor of its base class before any access occurs to inherited instance data. (This does not apply to value types, which need not have constructors.) (§[I.8.9.6.6]](#todo-missing-hyperlink))
+**CLS Rule 21:** An object constructor shall call some instance constructor of its base class before any access occurs to inherited instance data. (This does not apply to value types, which need not have constructors.) (§[I.8.9.6.6](i.8.9.6.6-constructors.md))
 
-**CLS Rule 22:** An object constructor shall not be called except as part of the creation of an object, and an object shall not be initialized twice. (§[I.8.9.6.6]](#todo-missing-hyperlink))
+**CLS Rule 22:** An object constructor shall not be called except as part of the creation of an object, and an object shall not be initialized twice. (§[I.8.9.6.6](i.8.9.6.6-constructors.md))
 
-**CLS Rule 23:** `System.Object` is CLS-compliant. Any other CLS-compliant class shall inherit from a CLS-compliant class. (§[I.8.9.9]](#todo-missing-hyperlink))
+**CLS Rule 23:** `System.Object` is CLS-compliant. Any other CLS-compliant class shall inherit from a CLS-compliant class. (§[I.8.9.9](i.8.9.9-object-type-inheritance.md))
 
-**CLS Rule 24:** The methods that implement the getter and setter methods of a property shall be marked SpecialName in the metadata. (§[I.8.11.3]](#todo-missing-hyperlink))
+**CLS Rule 24:** The methods that implement the getter and setter methods of a property shall be marked SpecialName in the metadata. (§[I.8.11.3](i.8.11.3-property-definitions.md))
 
 **CLS Rule 25:** No longer used. _[Note:_ In an earlier version of this standard, this rule stated "The accessibility of a property and of its accessors shall be identical." The removal of this rule allows, for example, public access to a getter while restricting access to the setter. _end note]_ (§[I.8.11.3](i.8.11.3-property-definitions.md))
 

docs/i.12.1.3-handling-of-floating-point-data-types.md

@@ -19,7 +19,7 @@ _[Note:_ The following examples show the most commonly encountered cases.
  (+infinity) - (+infinity) = NaN
  ```
 
-This standard does not specify the behavior of arithmetic operations on denormalized floatingpoint numbers, nor does it specify when or whether such representations should be created. This is in keeping with IEC 60559:1989. In addition, this standard does not specify how to access the exact bit pattern of NaNs that are created, nor the behavior when converting a **NaN** between 32-bit and 64-bit representation. All of this behavior is deliberately left implementation-specific. _end note]_
+This standard does not specify the behavior of arithmetic operations on denormalized floating-point numbers, nor does it specify when or whether such representations should be created. This is in keeping with IEC 60559:1989. In addition, this standard does not specify how to access the exact bit pattern of NaNs that are created, nor the behavior when converting a **NaN** between 32-bit and 64-bit representation. All of this behavior is deliberately left implementation-specific. _end note]_
 
 For purposes of comparison, infinite values act like a number of the correct sign, but with a very large magnitude when compared with finite values. For comparison purposes, **NaN** is 'unordered' (see `clt`, `clt.un`).
 

docs/i.12.6.5-locks-and-threads.md

@@ -6,9 +6,9 @@ The logical abstraction of a thread of control is captured by an instance of the
 
 2. **Explicit locks and monitors.** These are provided in the class library, see `System.Threading.Monitor.` Many of the methods in the `System.Threading.Monitor` class accept an `Object` as argument, allowing direct access to the same lock that is used by synchronized methods. While the CLI is responsible for ensuring correct protocol when this lock is only used by synchronized methods, the user must accept this responsibility when using explicit monitors on these same objects.
 
-3. **Volatile reads and writes.** The CIL includes a prefix, `volatile.`, that specifies that the subsequent operation is to be performed with the cross-thread visibility constraints described in §[I.12.6.7]](#todo-missing-hyperlink). In addition, the class library provides methods to perform explicit volatile reads (`System.Thread.VolatileRead`) and writes (`System.Thread.VolatileWrite`), as well as barrier synchronization (`System.Thread.MemoryBarrier`).
+3. **Volatile reads and writes.** The CIL includes a prefix, `volatile.`, that specifies that the subsequent operation is to be performed with the cross-thread visibility constraints described in §[I.12.6.7](i.12.6.7-volatile-reads-and-writes.md). In addition, the class library provides methods to perform explicit volatile reads (`System.Thread.VolatileRead`) and writes (`System.Thread.VolatileWrite`), as well as barrier synchronization (`System.Thread.MemoryBarrier`).
 
-4. **Built-in atomic reads and writes.** All reads and writes of certain properly aligned data types are guaranteed to occur atomically. See §[I.12.6.6]](#todo-missing-hyperlink).
+4. **Built-in atomic reads and writes.** All reads and writes of certain properly aligned data types are guaranteed to occur atomically. See §[I.12.6.6](i.12.6.6-atomic-reads-and-writes.md).
 
 5. **Explicit atomic operations.** The class library provides a variety of atomic operations in the `System.Threading.Interlocked` class. These operations (e.g., `Increment`, `Decrement`, `Exchange`, and `CompareExchange`) perform implicit acquire/release operations.
 

docs/i.3-normative-references.md

@@ -22,7 +22,7 @@ ISO/IEC 11578:1996, _Information Technology — Open Systems Interconnection
 
 ISO/IEC 14882:2011, _Programming languages — C++._
 
-ISO/IEC 23270:2006, _Programming languages — C#.
+ISO/IEC 23270:2006, _Programming languages — C#._
 
 RFC-768, _User Datagram Protocol._ J. Postel. 1980, August.
 
@@ -52,7 +52,7 @@ RFC-1764. _The PPP XNS IDP Control Protocol (XNSCP)._ Network Working Group. S.
 
 RFC-1766, _Tags for the Identification of Languages._ Network Working Group. H. Alvestrand. 1995, March.
 
-RFC-1792. _TCP/IPX Connection Mib Specification._Network Working Group. T. Sung. 1995, April. 
+RFC-1792. _TCP/IPX Connection Mib Specification._ Network Working Group. T. Sung. 1995, April.
 
 RFC-2236. _Internet Group Management Protocol, Version 2._ Network Working Group. W. Fenner. 1997, November.
 

docs/i.7.2.3-cls-extender.md

@@ -12,7 +12,7 @@ A CLS extender is a language or tool that is designed to allow programmers to bo
 
  * Place any CLS-compliant custom attribute on all appropriate elements of metadata.
 
- * Define new CLS-compliant (non-generic) types that extend any (non-sealed) CLScompliant base type. Valid base types include normal (non-generic) types and also fully constructed generic types.
+ * Define new CLS-compliant (non-generic) types that extend any (non-sealed) CLS-compliant base type. Valid base types include normal (non-generic) types and also fully constructed generic types.
 
 _[Note:_ Extenders should consider supporting:
 

docs/i.8.2.1.1-managed-pointers-and-related-types.md

@@ -1,9 +1,9 @@
 ## I.8.2.1.1 Managed pointers and related types
 
-A **managed pointer** (§[I.12.1.1.2](i.12.1.1.2-object-reference-and-managed-pointer-types-o-and-ref.md)), or **byref** (§[I.8.6.1.3](#todo-missing-hyperlink), §[I.12.4.1.5.2](i.12.4.1.5.2-by-reference-parameters.md)), can point to a local variable, parameter, field of a compound type, or element of an array. However, when a call crosses a remoting boundary (see §[I.12.5](i.12.5-proxies-and-remoting.md)) a conforming implementation can use a copy-in/copyout mechanism instead of a managed pointer. Thus programs shall not rely on the aliasing behavior of true pointers. Managed pointer types are only allowed for  local variable (§[I.8.6.1.3](#todo-missing-hyperlink)) and parameter signatures (§[I.8.6.1.4](#todo-missing-hyperlink)); they cannot be used for field signatures (§[I.8.6.1.2](#todo-missing-hyperlink)), as the element type of an array (§[I.8.9.1](i.8.9.1-array-types.md)), and boxing a value of managed pointer type is disallowed (§[I.8.2.4](i.8.2.4-boxing-and-unboxing-of-values.md)). Using a managed pointer type for the return type of methods (§[I.8.6.1.5](#todo-missing-hyperlink)) is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)).
+A **managed pointer** (§[I.12.1.1.2](i.12.1.1.2-object-reference-and-managed-pointer-types-o-and-ref.md)), or **byref** (§[I.8.6.1.3](#todo-missing-hyperlink), §[I.12.4.1.5.2](i.12.4.1.5.2-by-reference-parameters.md)), can point to a local variable, parameter, field of a compound type, or element of an array. However, when a call crosses a remoting boundary (see §[I.12.5](i.12.5-proxies-and-remoting.md)) a conforming implementation can use a copy-in/copy-out mechanism instead of a managed pointer. Thus programs shall not rely on the aliasing behavior of true pointers. Managed pointer types are only allowed for  local variable (§[I.8.6.1.3](#todo-missing-hyperlink)) and parameter signatures (§[I.8.6.1.4](#todo-missing-hyperlink)); they cannot be used for field signatures (§[I.8.6.1.2](#todo-missing-hyperlink)), as the element type of an array (§[I.8.9.1](i.8.9.1-array-types.md)), and boxing a value of managed pointer type is disallowed (§[I.8.2.4](i.8.2.4-boxing-and-unboxing-of-values.md)). Using a managed pointer type for the return type of methods (§[I.8.6.1.5](#todo-missing-hyperlink)) is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)).
 
 _[Rationale:_ For performance reasons items on the GC heap may not contain references to the interior of other GC objects, this motivates the restrictions on fields and boxing. Further returning a managed pointer which references a local or parameter variable may cause the reference to outlive the variable, hence it is not verifiable. _end rationale]_
 
 There are three value types in the Base Class Library (see [Partition IV - BCL](#todo-missing-hyperlink)): `System.TypedReference`, `System.RuntimeArgumentHandle`, and `System.ArgIterator`; which are treated specially by the CLI.
 
-The value type `System.TypedReference`, or **typed reference** or **typedref**, (§[I.8.2.2](i.8.2.2-built-in-value-and-reference-types.md), §[I.8.6.1.3](#todo-missing-hyperlink), §[I.12.4.1.5.3]) contains both a managed pointer to a location and a runtime representation of the type that can be stored at that location. Typed references have the same restrictions as byrefs. Typed references are created by the CIL instruction mkrefany (see [Partition III](#todo-missing-hyperlink)). The value types `System.RuntimeArgumentHandle` and `System.ArgIterator` (see [Partition IV](#todo-missing-hyperlink) and CIL instruction `arglist` in [Partition III](#todo-missing-hyperlink)), contain pointers into the VES stack. They can be used for local variable and parameter signatures. The use of these types for fields, method return types, the element type of an array, or in boxing is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)). These two types are referred to as **byref-like** types.
+The value type `System.TypedReference`, or **typed reference** or **typedref**, (§[I.8.2.2](i.8.2.2-built-in-value-and-reference-types.md), §[I.8.6.1.3](#todo-missing-hyperlink), §[I.12.4.1.5.3](i.12.4.1.5.3-typed-reference-parameters.md)) contains both a managed pointer to a location and a runtime representation of the type that can be stored at that location. Typed references have the same restrictions as byrefs. Typed references are created by the CIL instruction mkrefany (see [Partition III](#todo-missing-hyperlink)). The value types `System.RuntimeArgumentHandle` and `System.ArgIterator` (see [Partition IV](#todo-missing-hyperlink) and CIL instruction `arglist` in [Partition III](#todo-missing-hyperlink)), contain pointers into the VES stack. They can be used for local variable and parameter signatures. The use of these types for fields, method return types, the element type of an array, or in boxing is not verifiable (§[I.8.8](i.8.8-type-safety-and-verification.md)). These two types are referred to as **byref-like** types.

docs/i.8.5.1-valid-names.md

@@ -4,7 +4,7 @@ All name comparisons are done on a byte-by-byte (i.e., case sensitive, locale-in
 
 > #### CLS Rule 4:
 >
-> Assemblies shall follow Annex 7 of Technical Report 15 of the Unicode Standard 3.0 governing the set of characters permitted to start and be included in identifiers, available online at http://www.unicode.org/unicode/reports/tr15/tr15-18.html. Identifiers shall be in the canonical format defined by Unicode Normalization Form C. For CLS purposes, two identifiers are the same if their lowercase mappings (as specified by the Unicode locale-insensitive, one-toone lowercase mappings) are the same. That is, for two identifiers to be considered different under the CLS they shall differ in more than simply their case. However, in order to override an inherited definition the CLI requires the precise encoding of the original declaration be used.
+> Assemblies shall follow Annex 7 of Technical Report 15 of the Unicode Standard 3.0 governing the set of characters permitted to start and be included in identifiers, available online at http://www.unicode.org/unicode/reports/tr15/tr15-18.html. Identifiers shall be in the canonical format defined by Unicode Normalization Form C. For CLS purposes, two identifiers are the same if their lowercase mappings (as specified by the Unicode locale-insensitive, one-to-one lowercase mappings) are the same. That is, for two identifiers to be considered different under the CLS they shall differ in more than simply their case. However, in order to override an inherited definition the CLI requires the precise encoding of the original declaration be used.
 > _[Note:_
 >
 > **CLS (consumer):** Need not consume types that violate CLS Rule 4, but shall have a mechanism to allow access to named items that use one of its own keywords as the name.

docs/i.8.5.3.3-security-permissions.md

@@ -4,6 +4,6 @@ Access to members is also controlled by security demands that can be attached to
 
  * An **inheritance demand**. When attached to a type, it requires that any type that wishes to inherit from this type shall have the specified security permission.  When attached to a non-final virtual method, it requires that any type that wishes to override this method shall have the specified permission.  It shall not be attached to any other member.
 
- * A ***reference demand**.  Any attempt to resolve a reference to the marked item shall have specified security permission.
+ * A **reference demand**.  Any attempt to resolve a reference to the marked item shall have specified security permission.
 
 Only one demand of each kind can be attached to any item. Attaching a security demand to an assembly implies that it is attached to all types in the assembly unless another demand of the same kind is attached to the type. Similarly, a demand attached to a type implies the same demand for all members of the type unless another demand of the same kind is attached to the member.  For additional information, see Declarative Security in [Partition II](ii.20-declarative-security.md), and the classes in the `System.Security` namespace in [Partition IV](#todo-missing-hyperlink).

docs/i.8.8-type-safety-and-verification.md

@@ -4,6 +4,6 @@ Since types specify contracts, it is important to know whether a given implement
 
 Type-safe implementations only store values described by a type signature in a location that is *assignable-to* (§[I.8.7.3](i.8.7.3-general-assignment-compatibility.md)) the location signature of the location (see §[I.8.6.1](i.8.6.1-signatures.md)). Type-safe implementations never apply an operation to a value that is not defined by the exact type of the value. Type-safe implementations only access locations that are both visible and accessible to them. In a type-safe implementation, the exact type of a value cannot change.
 
-**Verification** is a mechanical process of examining an implementation and asserting that it is type-safe. Verification is said to succeed if the process proves that an implementation is typesafe. Verification is said to fail if that process does not prove the type safety of an implementation. Verification is necessarily conservative: it can report failure for a type-safe implementation, but it never reports success for an implementation that is not type-safe. For example, most verification processes report implementations that do pointer-based arithmetic as failing verification, even if the implementation is, in fact, type-safe.
+**Verification** is a mechanical process of examining an implementation and asserting that it is type-safe. Verification is said to succeed if the process proves that an implementation is type-safe. Verification is said to fail if that process does not prove the type safety of an implementation. Verification is necessarily conservative: it can report failure for a type-safe implementation, but it never reports success for an implementation that is not type-safe. For example, most verification processes report implementations that do pointer-based arithmetic as failing verification, even if the implementation is, in fact, type-safe.
 
 There are many different processes that can be the basis of verification. The simplest possible process simply says that all implementations are not type-safe. While correct and efficient this is clearly not particularly useful. By spending more resources (time and space) a process can correctly identify more type-safe implementations. It has been proven, however, that no mechanical process can, in finite time and with no errors, correctly identify all implementations as either type-safe or not type-safe. The choice of a particular verification process is thus a matter of engineering, based on the resources available to make the decision and the importance of detecting the type safety of different programming constructs.