From 0673f7014d68bbcd6878be964842b1e126336e94 Mon Sep 17 00:00:00 2001 From: Mert Date: Sun, 1 Mar 2015 03:25:52 +0200 Subject: [PATCH] Changed to heading to Verifiable Code - ... --- Documentation/intro-to-clr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/intro-to-clr.md b/Documentation/intro-to-clr.md index 206abc3..6520c5b 100644 --- a/Documentation/intro-to-clr.md +++ b/Documentation/intro-to-clr.md @@ -140,7 +140,7 @@ For type safety, conceptually each memory allocation is associated with a 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. -### Enforcing Verifiable Code (Memory and Type Safety) +### Verifiable Code - Enforcing Memory and Type Safety Conceptually, to enforce type safety, every operation that the program performs has to be checked to ensure that it is operating on memory that was typed in a way that is compatible with the operation. While the system could do this all at runtime, it would be very slow. Instead, the CLR has the concept of [CIL][cil-spec] verification, where a static analysis is done on the [CIL][cil-spec] (before the code is run) to confirm that most operations are indeed type-safe. Only when this static analysis can't do a complete job are runtime checks necessary. In practice, the number of run-time checks needed is actually very small. They include the following operations: -- 2.7.4