CVS difference for ais/ai-00067.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00067.txt

--- ais/ai-00067.txt	2000/04/14 01:45:06	1.5
+++ ais/ai-00067.txt	2000/06/20 04:22:42	1.6
@@ -52,20 +52,20 @@
 
 !recommendation
 
-An implementation conforming to the SS annex must support a pragma
+An implementation conforming to the Safety and Security annex must support a pragma
 Restrictions(Max_Tasks => E), where E is a static expression whose value
 is zero.  If such a pragma applies to a given compilation unit, then for
-an implementation conforming to the RT or SS annex (or both), the
-compilation unit is illegal if it contains an object_declaration or
+an implementation conforming to the Real-Time or Safety and Security annex (or
+both), the compilation unit is illegal if it contains an object_declaration or
 allocator, where the type of the created object is a task type, or is a
 composite type with some subcomponent type that is a task type.
 
-An implementation conforming to the SS annex must support a pragma
+An implementation conforming to the Safety and Security annex must support a pragma
 Restrictions(Max_Asynchronous_Select_Nesting => E), where E is a static
 expression whose value is zero.  If such a pragma applies to a given
-compilation unit, then for an implementation conforming to the RT or SS
-annex (or both), the compilation unit is illegal if it contains an
-asynchronous_select.
+compilation unit, then for an implementation conforming to the Real-Time
+or Safety and Security annex (or both), the compilation unit is illegal if it
+contains an asynchronous_select.
 
 !wording
 
@@ -75,7 +75,8 @@
 
 The intent is that it should be possible for a single implementation to
 comply with all of the Specialized Needs Annexes.  Therefore, there
-cannot be contradictory requirements in two different SN Annexes.
+cannot be contradictory requirements in two different Specialized Needs
+Annexes.
 
 "Max_Tasks is 0" should be interpreted to mean that a static expression
 is given, and its value is zero.  Clearly, we cannot require
@@ -101,8 +102,8 @@
 
 The following possible interpretations exist:
 
-    1. If the implementation supports the RT annex, the example program
-       is legal.  If the implementation supports the SS annex, the
+    1. If the implementation supports the Real-Time annex, the example program
+       is legal.  If the implementation supports the Safety and Security annex, the
        example is illegal.  We reject this interpretation, because it
        constitutes a contradiction between the two annexes.
 
@@ -110,7 +111,7 @@
        if either annex is supported.  This is the interpretation chosen.
 
     3. If the expression is statically zero, then the example is legal.
-       However, if the implementation conforms to the SS annex, then it
+       However, if the implementation conforms to the Safety and Security annex, then it
        must issue a warning message.  There is some precedent for
        requiring warning messages -- see 2.8(13).  This seems like a
        reasonable interpretation.  However, it seems better to simply
@@ -183,7 +184,7 @@
 !appendix
 
 !section D.7(00)
-!subject Pragma Restrictions in RT and SS annexes
+!subject Pragma Restrictions in RT and Safety and Security annexes
 !reference RM95-D.7(00)
 !reference RM95-H.4(00)
 !from Bob Duff
@@ -210,7 +211,7 @@
 ****************************************************************
 
 !section D.7(00)
-!subject Pragma Restrictions in RT and SS annexes
+!subject Pragma Restrictions in RT and Safety and Security annexes
 !reference RM95-D.7(00)
 !reference RM95-H.4(00)
 !reference as: 95-5214.b Robert A Duff 95-7-8
@@ -249,16 +250,16 @@
 annexes. I would not recommend the introduction of such distinction (there
 are other similar restrictions).
 
-We can also say that the RT requires run-time check and the SS annex
+We can also say that the RT requires run-time check and the Safety and Security annex
 requires *in addition* a pre-run-time check.
 
 In general, the Max_Task in the two annexes have quite a different purpose:
-In the SS, it largely intended to mean Tasking:yes/no, in the RT annex it is
+In the SS, it largely intended to mean Tasking:yes/no, in the Real-Time annex it is
 *intended* to have a value that will help pre-allocation of TCBs and sizing
 the task-id value (e.g. only 8-bits for 256 tasks).  Maybe it wasn't a good
 idea to use the same parameter name.
 
-In the context of the RT annex, there was a lot of debate (and controversy)
+In the context of the Real-Time annex, there was a lot of debate (and controversy)
 with respect to the place of these checks, and I would hate to disturb the
 consensus that was achieved.
 
@@ -273,7 +274,7 @@
 ****************************************************************
 
 !section D.7(00)
-!subject Pragma Restrictions in RT and SS annexes
+!subject Pragma Restrictions in RT and Safety and Security annexes
 !reference RM95-D.7(00)
 !reference RM95-H.4(00)
 !reference 95-5214.b Robert A Duff 95-7-8
@@ -285,7 +286,7 @@
 
    pazy@world.std.com (Offer Pazy) said (among other things):
 
-> We can also say that the RT requires run-time check and the SS annex
+> We can also say that the RT requires run-time check and the Safety and Security annex
 > requires *in addition* a pre-run-time check.
 
    I think that this is the only reasonable interpretation.  First,

Questions? Ask the ACAA Technical Agent