diff options
author | christos-P <cpaisios@gmail.com> | 2015-09-04 18:39:12 +0300 |
---|---|---|
committer | christos-P <cpaisios@gmail.com> | 2015-09-04 18:39:12 +0300 |
commit | 090aa8e939a5fcd83b75350ab8dcab95c60a4f65 (patch) | |
tree | 0a47d73407e32d1e73ca0e8fc2d61f8fdb1da882 /Documentation | |
parent | 6668a9b85352920a958fa5527dda12dc2f5886aa (diff) | |
download | coreclr-090aa8e939a5fcd83b75350ab8dcab95c60a4f65.tar.gz coreclr-090aa8e939a5fcd83b75350ab8dcab95c60a4f65.tar.bz2 coreclr-090aa8e939a5fcd83b75350ab8dcab95c60a4f65.zip |
minor correction
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/botr/intro-to-clr.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/Documentation/botr/intro-to-clr.md b/Documentation/botr/intro-to-clr.md index 3f9ce90c93..9f91b3ea7d 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 |