From a35fbf755a445de0272d21f5dc9248aa9fc19b2b Mon Sep 17 00:00:00 2001 From: eiffel-org Date: Mon, 20 Dec 2021 10:16:27 +0000 Subject: [PATCH] Fixed a typo. Updated wikipage Void-safety: Background, definition, and tools. (Signed-off-by:alexk). git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2344 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../void-safety-background-definition-and-tools.wiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/21.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki b/documentation/21.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki index 816bd29a..37c81164 100644 --- a/documentation/21.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki +++ b/documentation/21.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki @@ -1,4 +1,4 @@ -[[Property:modification_date|Mon, 20 Dec 2021 10:13:53 GMT]] +[[Property:modification_date|Mon, 20 Dec 2021 10:16:27 GMT]] [[Property:publication_date|Mon, 20 Dec 2021 10:13:53 GMT]] [[Property:link_title|Background and tools]] [[Property:title|Void-safety: Background, definition, and tools]] @@ -69,7 +69,7 @@ We know that in the context of certain code patterns, it is clear that it would Here a check is made to ensure x is not void. Then as long as no assignments to x are made in the interim, a feature f can be applied to x with the certainty that x will be attached at the time ... and importantly, this can be determined at compile time. So, we say that this code pattern is a CAP for x. -It is important to understand that in this example (and with other CAPs), x is allowed to be a local variable or formal argument only. That is, x may not be an attribute or general expression (with one exception which we will see [[#Stable attributes|below]]). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|section]], we will see that this is not quite such a limitations as it may appear at this point. +It is important to understand that in this example (and with other CAPs), x is allowed to be a local variable or formal argument only. That is, x may not be an attribute or general expression (with one exception which we will see [[#Stable attributes|below]]). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|section]], we will see that this is not quite such a limitation as it may appear at this point. {{note|You will find more useful information about CAPs in [[Creating a new void-safe project#More about CAPs|More about CAPs]]. Learn how certain code patterns are determined to be CAPs in [[What makes a Certified Attachment Pattern]]. }}