Version 1.3 of ai12s/ai12-0445-1.txt

Unformatted version of ai12s/ai12-0445-1.txt version 1.3
Other versions for file ai12s/ai12-0445-1.txt

!standard 3.2(8) 22-05-05 AI12-0445-1/03
!standard 3.10.2(20)
!standard 5.5.3(21/5)
!standard 5.5.3(27/5)
!standard 5.5.3(28/5)
!standard 5.5.3(29/5)
!standard 7.6.1(16/2)
!standard 9.6.1(82/2)
!standard 9.8(20/3)
!standard 10.1.1(24)
!standard 10.1.4(2)
!standard 11.1(6)
!standard 11.4.2(26/3)
!standard 12.5.1(1/3)
!standard 13.1(7/2)
!standard 13.3(37/2)
!standard 13.3(55)
!standard 13.3(58.13/5)
!standard 13.6(1/3)
!standard 13.6(2/5)
!standard 13.11(21.6/3)
!standard 13.11(22)
!standard 13.11.2(9/3)
!standard 13.11.3(5.2/4)
!standard 13.11.4(19/3)
!standard 13.13.2(56/3)
!standard 13.13.2(56.1/3)
!standard A.1(51)
!standard A.4.2(1)
!standard A.4.4(1)
!standard A.4.5(1)
!standard A.5.2(29/3)
!standard A.5.2(40.1/1)
!standard A.6(1/2)
!standard A.10.4(1)
!standard A.10.6(7)
!standard A.13(1)
!standard A.18.31(16/5)
!standard B.1(3)
!standard B.3.2(2)
!standard C.3(9)
!standard D.9(12)
!standard D.9(13)
!standard D.15(1/3)
!standard G(4)
!class presentation 22-04-28
!status Amendment 1-2012 22-05-05
!status ARG Approved 14-0-0 22-05-05
!status work item 22-04-28
!status received 22-02-18
!priority Critical
!difficulty Medium
!subject Rewordings of normative material
A large number of paragraphs need to be reworded.
ISO comment #20 says:
Verbal forms used to express provisions in the text do not always comply with the rules specified in the ISO/IEC Directives, Part 2. Do not use verbal forms ("could", "might", "need") that are not defined in the ISO/IEC Directives, Part 2.
The ISO "House Style" gives further information on this, essentially saying that they do not care whether the Standard reads well, they are more concerned with preciseness and lack of ambiguity.
As such, we need to remove any occurrences of those words from any normative text, and for some things that is complex.
Update the wording as described below.
Modify 3.2(8):
A /subtype/ of a given type is a combination of the type, a constraint on values of the type, and certain attributes specific to the subtype. The given type is called the /type of the subtype/. Similarly, the associated constraint is called the /constraint of the subtype/. The set of values of a subtype consists of the values of its type that satisfy its constraint and any exclusion of the null value. Such values /belong/ to the subtype. {The other values of the type are /outside/ the subtype.}
[We use "outside" in various notes (see AI12-0422-1), and it is already (dubiously) used in some Implementation Permissions (3.5.4(24) and 3.5.6(7/5)) - Editor.]
Modify 3.10.2(20):
* For determining whether one level is statically deeper than another when within a generic package body, the generic package is presumed to be instantiated at the same level as where it was declared; runtime checks are {required}[needed] in the case of more deeply nested instantiations.
[Replace "needed" - Editor.]
Modify 5.5.3(21/5):
Specifying the Parallel_Iterator aspect to be True for a callable entity indicates that the entity {is allowed to}[might] invoke the loop body procedure from multiple distinct logical threads of control. The Parallel_Iterator aspect for a subprogram shall be statically False if the subprogram allows exit.
["Might" is clearly better that "can" here, so we need a more substantial rewording. - Editor.]
Modify 5.5.3(27/5):
For the execution of a loop_statement with an iteration_scheme that has a procedural_iterator, the procedure denoted by the name or prefix of the iterator_procedure_call (the iterating procedure) is invoked, passing an access value designating the loop body procedure as a parameter. The iterating procedure then calls the loop body procedure zero or more times and returns, whereupon the loop_statement is complete. If the parallel reserved word is present, the iterating procedure {is allowed to}[might] invoke the loop body procedure from multiple distinct logical threads of control. The aspect_specification, if any, is elaborated prior to the invocation of the iterating procedure.
[See previous item. - Editor.]
Modify 5.5.3(28/5):
If the callable entity identified in the iterator_procedure_call allows exit, then it is a bounded error for a call of the loop body procedure to be performed from within an abort-deferred operation (see 9.8), unless the entire loop_statement was within the same abort-deferred operation. If detected, Program_Error is raised at the point of the call; otherwise, a transfer of control from the sequence_of_statements of the loop_statement {will}[might] not {necessarily} terminate the loop_statement, and the loop body procedure {can}[might] be called again.
["might not" needs to be replaced by other wording, "cannot" does not have the same meaning at all - Editor.]
Modify 5.5.3(29/5):
If a loop_statement with the procedural_iterator as its iteration_scheme (see 5.5) does not begin with the reserved word parallel, it is a bounded error if the loop body procedure is invoked from a different logical thread of control than the one that initiates the loop_statement. If detected, Program_Error is raised; otherwise, conflicts associated with concurrent executions of the loop body procedure can occur without being detected by the applicable conflict check policy (see 9.10.1). Furthermore, propagating an exception or making an attempt to exit in the presence of multiple threads of control {will}[might] not {necessarily} terminate the loop_statement, deadlock {can}[might] occur, or the loop body procedure {can}[might] be called again.
[See previous paragraph for comments - Editor.]
Modify 7.6.1(16/2):
* For an Adjust invoked as part of assignment operations other than those invoked as part of an assignment_statement, [other]{some of the} adjustments due to be performed [might or might not]{can} be performed, and then Program_Error is raised. During its propagation, finalization [might or might not]{may} be applied to objects whose Adjust failed. For an Adjust invoked as part of an assignment_statement, any other adjustments due to be performed are performed, and then Program_Error is raised.
["might or might not" is doubly bad. "can or cannot" doesn't make much sense. I thought of using "it is not specified whether other adjustments due to be performed are actually performed", but that's pretty long (and one would have to do something similar for the next sentence). Tucker suggested the above for the first part, but missed the second "might or might not". I wonder if "may" is better than "can" here (this is normative, so we can use "may") - Editor.]
Modify 9.6.1(82/2):
Returns a string form of the Date relative to the given Time_Zone. The format is "Year-Month-Day Hour:Minute:Second", where the Year is a 4-digit value, and all others are 2-digit values, of the functions defined in Calendar and Calendar.Formatting, including a leading zero, if {necessary}[needed]. The separators between the values are a minus, another minus, a colon, and a single space between the Day and Hour. If Include_Time_Fraction is True, the integer part of Sub_Seconds*100 is suffixed to the string as a point followed by a 2-digit value.
[Replace "needed" - Editor.]
Modify 9.8(20/3):
An attempt to execute an asynchronous_select as part of the execution of an abort-deferred operation is a bounded error. Similarly, an attempt to create a task that depends on a master that is included entirely within the execution of an abort-deferred operation is a bounded error. In both cases, Program_Error is raised if the error is detected by the implementation; otherwise, the operations proceed as they would outside an abort-deferred operation, except that an abort of the abortable_part or the created task {does not necessarily}[might or might not] have an effect.
["might or might not" is doubly bad, "can or cannot" is doesn't have the right meaning, so I tried the above rewording - Editor.]
Modify 10.1.1(24):
* The semantic dependences (see below) are the ones needed to check the compile-time rules across compilation unit boundaries; a compilation unit depends semantically on the other compilation units {necessary}[needed] to determine its legality. The visibility rules are based on the semantic dependences.
[Replace "needed" - Editor.]
Modify 10.1.4(2):
The declarative_items of the environment are library_items appearing in an order such that there are no forward semantic dependences. Each included subunit occurs in place of the corresponding stub. The visibility rules apply as if the environment were the outermost declarative region, except that with_clauses are {necessary}[needed] to make declarations of library units visible (see 10.1.2).
[Replace "needed" - Editor.]
Modify 11.1(6):
The execution of any construct raises Storage_Error if there is insufficient storage for that execution. The amount of storage {necessary}[needed] for the execution of constructs is unspecified.
[Replace "needed" - Editor.]
Modify 11.4.2(26/3):
If the result of a function call in an assertion is not {used}[needed] to determine the value of the assertion expression, an implementation is permitted to omit the function call. This permission applies even if the function has side effects.
[Replace "needed" - Editor.]
Modify 11.6(6/3):
* If an exception is raised due to the failure of a language-defined check, then upon reaching the corresponding exception_handler (or the termination of the task, if none), the external interactions that have occurred {have to}[need] reflect only that the exception was raised somewhere within the execution of the sequence_of_statements with the handler (or the task_body), possibly earlier (or later if the interactions are independent of the result of the checked operation) than that defined by the canonical semantics, but not within the execution of some abort-deferred operation or independent subprogram that does not dynamically enclose the execution of the construct whose check failed. An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and for which the Inline aspect is False. Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be disrupted by the raising of the exception, causing the object or its parts to become abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.
[Replace "need" - Editor.]
Modify 12.5.1(1/3):
In its most general form, the category determined for a formal private type is all types, but the category can be restricted to only nonlimited types or to only tagged types. Similarly, the category for a formal incomplete type is all types but the category can be restricted to only tagged types; unlike other formal types, the actual type [does not need to be able to be]{can be incompletely defined, and not ready to be} frozen (see 13.14). The category determined for a formal derived type is the derivation class rooted at the ancestor type.
[Replace "need to" - Editor.]
Modify 13.1(7/2):
The representation of an object consists of a certain number of bits (the size of the object). For an object of an elementary type, these are the bits that are normally read or updated by the machine code when loading, storing, or operating-on the value of the object. For an object of a composite type, these are the bits reserved for this object, and include bits occupied by subcomponents of the object. If the size of an object is greater than that of its subtype, the additional bits are padding bits. For an elementary object, these padding bits are normally read and updated along with the others. For a composite object, {it is unspecified whether} padding bits {are}[might not be] read or updated in any given composite operation[, depending on the implementation].
[Have to replace "might not", but "cannot" is wrong and "may not" is not allowed. - Editor]
Modify 13.3(37/2):
The recommended level of support for the Size attribute of objects is the same as for subtypes (see below), except that only a confirming Size clause {is required to}[need] be supported for an aliased elementary object.
[Replace "need". Could use a form of "should" here instead, maybe - Editor.]
Modify 13.3(55):
* The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits {necessary}[needed] to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation.
[Replace "needed" - Editor.]
Modify 13.3(58.13/5):
* If S is some other subtype, only confirming specifications of Object_Size [need]{are required to} be supported.
[Replace "need". Could use a form of "should" here instead, maybe - Editor.]
Modify 13.6(1/3):
A type_conversion (see 4.6) can be used to convert between two different representations of the same array or record. To convert an array from one representation to another, two array types [need to be declared] with matching component subtypes[,] and convertible index types{ are required}. If one type has Pack specified and the other does not, then explicit conversion can be used to pack or unpack an array.
[Replace "need to" - Editor.]
Modify 13.6(2/5):
To convert an untagged record from one representation to another, two record types with a common ancestor type [need to be declared]{are required}. Distinct representations can then be specified for the record types, and explicit conversion between the types can be used to effect a change in representation.
[Replace "need to" - Editor.]
Modify 13.11(21.6/3):
The number of calls to Allocate [needed]{that will be used} to implement an allocator for any particular type is unspecified. The number of calls to Deallocate [needed]{that will be used} to implement an instance of Unchecked_Deallocation (see 13.11.2) for any particular object is the same as the number of Allocate calls for that object.
[Replace "needed" - Editor.]
Modify 13.11(22):
An implementation shall document the set of values that a user-defined Allocate procedure [needs]{has} to accept for the Alignment parameter. An implementation shall document how the standard storage pool is chosen, and how storage is allocated by standard storage pools.
[Replace "needs". "Has" should be OK here, as this is already a requirement - Editor.]
Modify 13.11.2(9/3):
c) Free(X), when X is not equal to null first performs finalization of
the object designated by X (and any coextensions of the object - see 3.10.2), as described in 7.6.1. It then deallocates the storage occupied by the object designated by X (and any coextensions). If the storage pool is a user-defined object, then the storage is deallocated by calling Deallocate as described in 13.11. There is one exception: if the object being freed contains tasks, {it is unspecified whether} the object {is}[might not be] deallocated.
[Have to replace "might not", but "cannot" is wrong and "may not" is not allowed. - Editor]
Modify 13.11.3(5.2/4):
Otherwise, the expected type for the Default_Storage_Pool aspect is Root_Storage_Pool'Class and the aspect_definition shall be a name that denotes a variable. This aspect overrides any Default_Storage_Pool pragma that {applies}[might apply] to the generic unit; if the aspect is not specified, the default pool of the instance is that defined for the generic unit.
[We don't need "might" here, as we already have "any" to say that there doesn't have to be one. So we can just use "applies". - Editor]
Modify 13.11.4(19/3):
A subpool object is an object of a type descended from Root_Subpool. Typically, subpool objects are managed by the containing storage pool; only the handles [need]{have to} be exposed to clients of the storage pool. Subpool objects are designated by subpool handles, and are the run-time representation of a subpool.
[Replace "need" - Editor.]
Modify 13.13.2(56/3):
The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type [needed]{used} to implement an explicit invocation of a stream-oriented attribute shall take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3).
[Replace "needed" - Editor.]
Modify 13.13.2(56.1/3):
If T is a discriminated type and its discriminants have defaults, then in two cases an execution of the default implementation of S'Read is not required to create an anonymous object of type T: If the discriminant values that are read in are equal to the corresponding discriminant values of Item, then {creation of a new} [no] object of type T [need be created] {can be bypassed} and Item may be used instead. If they are not equal and Item is a constrained variable, then Constraint_Error may be raised at that point, before any further values are read from the stream and before the object of type T is created.
[Replace "need be" - Editor.]
Modify A.1(51):
An implementation may provide additional predefined integer types and additional predefined floating point types. [Not]{Some or} all of these types [need have names]{may be anonymous}.
Modify A.4.2(1):
The package Strings.Maps defines the types, operations, and other entities {necessary}[needed] for character sets and character-to-character mappings.
[Replace "needed" - Editor.]
Modify A.4.4(1):
The language-defined package Strings.Bounded provides a generic package each of whose instances yields a private type Bounded_String and a set of operations. An object of a particular Bounded_String type represents a String whose low bound is 1 and whose length can vary conceptually between 0 and a maximum size established at the generic instantiation. The subprograms for fixed-length string handling are either overloaded directly for Bounded_String, or are modified as {necessary}[needed] to reflect the variability in length. Additionally, since the Bounded_String type is private, appropriate constructor and selector operations are provided.
[Replace "needed" - Editor.]
Modify A.4.5(1):
The language-defined package Strings.Unbounded provides a private type Unbounded_String and a set of operations. An object of type Unbounded_String represents a String whose low bound is 1 and whose length can vary conceptually between 0 and Natural'Last. The subprograms for fixed-length string handling are either overloaded directly for Unbounded_String, or are modified as {necessary}[needed] to reflect the flexibility in length. Since the Unbounded_String type is private, relevant constructor and selector operations are provided.
[Replace "needed" - Editor.]
Modify A.5.2(29/3):
An object of the private type State can be used to hold the internal state of a generator. Such objects are only {necessary}[needed] if the application is designed to save and restore generator states or to examine or manufacture them. The implicit initial value of type State corresponds to the implicit initial value of all generators.
[Replace "needed" - Editor.]
Modify A.5.2(40.1/1):
It is a bounded error to invoke Value with a string that is not the image of any generator state. If the error is detected, Constraint_Error or Program_Error is raised. Otherwise, a call to Reset with the resulting state will produce a generator such that calls to Random with this generator will produce a sequence of values of the appropriate subtype, but which {are}[might] not {necessarily}[be] random in character. That is, the sequence of values {do not necessarily}[might not] fulfill the implementation requirements of this subclause.
[The usual fixes for "might not" don't work here. "Cannot" is too definite (we don't know that the sequence is bad, just that it might be). We fall back on the "necessarily" crutch. Tucker had a suggestion that did not replace the first "might", so it wasn't used - Editor.]
Modify A.6(1/2):
Input-output is provided through language-defined packages, each of which is a child of the root package Ada. The generic packages Sequential_IO and Direct_IO define input-output operations applicable to files containing elements of a given type. The generic package Storage_IO supports reading from and writing to an in-memory buffer. Additional operations for text input-output are supplied in the packages Text_IO, Wide_Text_IO, and Wide_Wide_Text_IO. Heterogeneous input-output is provided through the child packages Streams.Stream_IO and Text_IO.Text_Streams (see also 13.13). The package IO_Exceptions defines the exceptions [needed]{used} by the predefined input-output packages.
[Replace "needed" - Editor.]
Modify A.10.4(1):
The subprograms described in this subclause are concerned with the line and page structure of a file of mode Out_File or Append_File. They operate either on the file given as the first parameter, or, in the absence of such a file parameter, on the current default output file. They provide for output of text with a specified maximum line length or page length. In these cases, line and page terminators are output implicitly and automatically when {necessary}[needed]. When line and page lengths are unbounded (that is, when they have the conventional value zero), as in the case of a newly opened file, new lines and new pages are only started when explicitly called for.
[Replace "needed" - Editor.]
Modify A.10.6(7):
Any Put procedure, for an item of a numeric or an enumeration type, outputs the value of the item as a numeric literal, identifier, or character literal, as appropriate. This is preceded by leading spaces if required by the Format parameters Width or Fore (as described in later subclauses), and then a minus sign for a negative value; for an enumeration type, the spaces follow instead of leading. The format given for a Put procedure is overridden if it is insufficiently wide, by using the minimum {necessary}[needed] width.
[Replace "needed" - Editor.]
Modify A.13(1):
The package IO_Exceptions defines the exceptions [needed]{used} by the predefined input-output packages.
Modify A.18.31(16/5):
The Implementation Advice about the Move and Swap operations is deleted for bounded holders; these operations can copy elements as {necessary}[needed].
[Replace "needed" - Editor.]
Modify B.1(3):
A pragma Linker_Options is used to specify the system linker parameters {necessary}[needed] when a given compilation unit is included in a partition.
[Replace "needed" - Editor.]
Modify B.3.2(2):
The generic allows two styles of usage: one in which the array is terminated by a special terminator element; and another in which the programmer [needs to keep]{keeps} track of the length.
[Replace "needs to" - Editor.]
Modify C.3(9):
The implementation shall provide a mechanism to determine the minimum stack space that is {necessary}[needed] for each interrupt handler and to reserve that space for the execution of the handler. This space should accommodate nested invocations of the handler where the system permits this.
[Replace "needed" - Editor.]
Modify D.9(12):
* An upper bound on the lateness of a delay_relative_statement, for a positive value of the delay expression, in a situation where the task has sufficient priority to preempt the processor as soon as it becomes ready, and [does not need to wait]{can proceed without waiting} for any other execution resources. The upper bound is expressed as a function of the value of the delay expression. The lateness is obtained by subtracting the value of the delay expression from the actual duration. The actual duration is measured from a point immediately before a task executes the delay_statement to a point immediately after the task resumes execution following this statement.
[Replace "need to" - Editor.]
Modify D.9(13):
* An upper bound on the lateness of a delay_until_statement, in a situation where the value of the requested expiration time is after the time the task begins executing the statement, the task has sufficient priority to preempt the processor as soon as it becomes ready, and it [does not need to wait]{can proceed without waiting} for any other execution resources. The upper bound is expressed as a function of the difference between the requested expiration time and the clock value at the time the statement begins execution. The lateness of a delay_until_statement is obtained by subtracting the requested expiration time from the real time that the task resumes execution following this statement.
[Replace "need to" - Editor.]
Modify D.15(1/3):
This subclause describes a language-defined package to allow user-defined protected procedures to be executed at a specified time without the [need for]{use of} a task or a delay statement.
[Replace "need for" - Editor.]
Modify G(4):
* a mode ("relaxed mode"), in which {there are} no accuracy or other numeric performance requirements [need]{to} be satisfied, as for implementations not conforming to the Numerics Annex;
[Replace "need" - Editor.]
[A number of paragraphs that contain forms of the word "need" and are not uses of Ada technical terms but that we do not propose to changes can be found at the start of the !appendix - Editor.]
To summarize the ISO rules from the Directives part 2 (often referred to as the drafting standard):
Requirements use "shall" preferably, or phrases involving forms of "require", "has to", or "it is necessary". "Must" is not allowed (it can be used for external requirements, such as government laws, but that usually doesn't apply to us).
Recommendations use "should" preferably, or phrases involving forms of "recommend" or "ought to".
Permissions should use "may" preferably, or phrases using forms of "permit" or "allow". "Might" is not allowed in this context. Negative forms are not allowed (no "may not"); permissions must be positive. A quote: "Rather than using negative permissions, either rewrite the sentence to state what is permitted, or rewrite as a requirement/recommendation not to do something."
Possibility should use "can", or phrases using forms of "able" or "possible".
ISO has taken this further and does not want to see "might", "could", or "need" at all; they assume that they are being used in one of the above contexts. I don't know where "need" comes from (other than the "House Style", but that's not normative), the Directives never mentions it as a word to avoid, and in fact it uses the word "needs" with the meaning of desires repeatedly. But the Directives is clear that one should not use any words other than the above to express requirements, recommendations, or permissions.
We have a particular problem with "need not", used frequently to get around not being able to say "may not". That is discussed and handled in AI12-0444-1. [Editor's note: one case of "could cause" is also in AI12-0444-1, as all of the related paragraphs use both "need not" and "could cause".]
Note that while some phrases are given meanings, other uses of the words seem to be allowed by the Directives. For instance, "necessary" is used in many contexts in the Directives that are not requirements.
We handle occurrences of "must" in AI12-0438-1, and simple changes where some other word should be replaced by "can" in AI12-0439-1.
The remaining cases are handled in this AI.
The editor has created a file that contains just the normative text of the Standard. In this file, we have the following number of occurrences:
must 11 might 68 could 16 need 215 (58 of these are "needs", mostly in "needs finalization")
(48 of these are "needed", which is a technical term
when used with compilation units. In order to convince ISO this is OK, this term should be defined in the "terms" (probably along with "mentioned")).
(74 of these are "need not", which should not be
used but has no easy replacement).
We might be able to argue that "need" is not mentioned in the drafting document, but even so we ought to get rid of as many of those as possible.
There are nearly 200 paragraphs here that probably need fixing, and there is not a one-size-fits all solution. Many of the occurrences of "could" and "might" could be replaced by "can", but certainly not all.
We could consider making wording changes only for the ISO version (new commands would be needed in the formatter to support that if is done a lot
- currently, we can only do that on a full paragraph basis or with a few
macros - but new commands should not be hard to define and implement).
No ASIS effect.
!ACATS test
No ACATS test should be needed, no change in meaning is intended and these are notes anyway.

Here is wording involving forms of "need" that we won't try to fix:
[Note: There are also many technical uses of "need" that we are not changing,
and ISO appears to be primarily worried about "need to" and "need not", so
it's fairly unlikely that they will look at them in enough detail to raise
an objection.]

3.5.10 Operations of Fixed Point Types

4   S'Fore      S'Fore yields the minimum number of characters needed before
                the decimal point for the decimal representation of any value
                of the subtype S, assuming that the representation does not
                include an exponent, but includes a one-character prefix that
                is either a minus sign or a space. (This minimum number does
                not include superfluous zeros or underlines, and is at least
                2.) The value of this attribute is of the type

[Tucker felt that this should not be changed. He said: "Refuse to believe ISO 
will object to this." Not having any idea myself, I've left it out - Editor.]

5   S'Aft       S'Aft yields the number of decimal digits needed after the
                decimal point to accommodate the delta of the subtype S,
                unless the delta of the subtype S is greater than 0.1, in
                which case the attribute yields the value one. (S'Aft is the
                smallest positive integer N for which (10**N)*S'Delta is
                greater than or equal to one.) The value of this attribute is
                of the type universal_integer.

[See previous paragraph.]

A.10.9 Input-Output for Real Types

23          Outputs the value of the parameter Item as a decimal literal with
            the format defined by Fore, Aft and Exp. If the value is negative,
            or if Num is a floating point type where Num'Signed_Zeros is True
            and the value is a negatively signed zero, then a minus sign is
            included in the integer part. If Exp has the value zero, then the
            integer part to be output has as many digits as are needed to
            represent the integer part of the value of Item, overriding Fore
            if necessary, or consists of the digit zero if the value of Item
            has no integer part.

[Tucker felt that this should not be changed. He said: "This is consistent
with my earlier recommendation when talking about number of digits needed 
for various representations." My usual suggestion would leave this wording
with too many "necessary"s, so no change was made - Editor.]

26          If Exp has the value zero, there is no exponent part. If Exp has a
            value greater than zero, then the exponent part to be output has
            as many digits as are needed to represent the exponent part of the
            value of Item (for which a single digit integer part is used), and
            includes an initial sign (plus or minus). If the exponent part to
            be output has fewer than Exp characters, including the sign, then
            leading zeros precede the digits, to make up the difference. For
            the value 0.0 of Item, the exponent has the value zero.

[Tucker wanted to leave this unchanged in order to be consistent with the other
similar paragraphs that we are not changing - Editor.]

A.18.2 The Generic Package Containers.Vectors

115/3       If the capacity of Container is already greater than or equal to
            Capacity, then Reserve_Capacity has no effect. Otherwise,
            Reserve_Capacity allocates additional storage as necessary to
            ensure that the length of the resulting vector can become at least
            the value Capacity without requiring an additional call to
            Reserve_Capacity, and is large enough to hold the current length
            of Container. Reserve_Capacity then, as necessary, moves elements
            into the new storage and deallocates any storage no longer needed.
            Any exception raised during allocation is propagated and Container
            is not modified.

[Tucker suggests not changing. We could have used a word like "required" there,
but that seems unnecessary - Editor.]

                                   Annex H

                           High Integrity Systems

1/2 This Annex addresses requirements for high integrity systems (including
safety-critical systems and security-critical systems). It provides facilities
and specifies documentation requirements that relate to several needs:

[I believe this use of the word "needs" is OK, as it appears several times in
the Directives themselves.]


Questions? Ask the ACAA Technical Agent