From 090aa8e939a5fcd83b75350ab8dcab95c60a4f65 Mon Sep 17 00:00:00 2001 From: christos-P Date: Fri, 4 Sep 2015 18:39:12 +0300 Subject: [PATCH] minor correction --- Documentation/botr/intro-to-clr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/botr/intro-to-clr.md b/Documentation/botr/intro-to-clr.md index 3f9ce90..9f91b3e 100644 --- a/Documentation/botr/intro-to-clr.md +++ b/Documentation/botr/intro-to-clr.md @@ -140,7 +140,7 @@ By using these operators instead of the lower-level (and unsafe) _memory-fetch_ 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 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. -One the most important of these type-specific guarantees is that the visibility attributes associated with a type (and in particular with fields) are enforced. Thus, if a field is declared to be private (accessible only by the methods of the type), then that privacy will indeed be respected by all other type-safe code. For example, a particular type might declare a count field that represents the count of items in a table. Assuming the fields for the count and the table are private, and assuming that the only code that updates them updates them together, there is now a strong guarantee (across all type-safe code) that the count and the number of items in the table are indeed in sync. When reasoning about programs, programmers use the concept of type safety all the time, whether they know it or not. The CLR elevates type-safety from being simply a programming language/compiler convention, to something that can be strictly enforced at run time. +One of the most important of these type-specific guarantees is that the visibility attributes associated with a type (and in particular with fields) are enforced. Thus, if a field is declared to be private (accessible only by the methods of the type), then that privacy will indeed be respected by all other type-safe code. For example, a particular type might declare a count field that represents the count of items in a table. Assuming the fields for the count and the table are private, and assuming that the only code that updates them updates them together, there is now a strong guarantee (across all type-safe code) that the count and the number of items in the table are indeed in sync. When reasoning about programs, programmers use the concept of type safety all the time, whether they know it or not. The CLR elevates type-safety from being simply a programming language/compiler convention, to something that can be strictly enforced at run time. ### Verifiable Code - Enforcing Memory and Type Safety -- 2.7.4