Version 1.7 of ai05s/ai05-0062-1.txt

Unformatted version of ai05s/ai05-0062-1.txt version 1.7
Other versions for file ai05s/ai05-0062-1.txt

!standard 7.4(6/2)          08-04-18 AI05-0062-1/03
!standard 7.4(7.1/2)
!class binding interpretation 07-08-21
!status Amendment 201Z 08-11-26
!status WG9 Approved 08-06-20
!status ARG Approved 8-0-1 06-11-10
!status work item 07-08-21
!status received 07-08-21
!priority Low
!difficulty Easy
!qualifier Error
!subject Null exclusions and deferred constants
A full constant may have a null exclusion even if its associated deferred constant does not.
ACATS 3.0 test B740002 has the following example:
package B740002 is
type Priv_Comp is private;
type Acc_to_Priv is access all Priv_Comp;
Cnst_Priv_22 : constant Acc_to_Priv;
type Priv_Comp is ... Priv_Obj : aliased Priv_Comp;
Cnst_Priv_22 : constant not null Acc_to_Priv := Priv_Obj'access; -- OK?
end B740002;
The test writer thought that this constant was legal based on the wording of 7.4(7.1/2) [which is reinforced by AARM note 7.4(7.a.1/2)], which is asymmetrical.
However, a compiler writer has pointed out that 7.4(6/2) requires that the subtype_indications statically match, and that the subtype_indications include the null_exclusion. Note that this is different than renames and parameters, where the null_exclusion is separate from the subtype_mark, and thus matching only applies to that subtype_mark.
What is the intent here?
(See Summary.)
In 7.4(6/2), change
...then the {constraint}[subtype] defined by the subtype_indication in the full declaration shall match it statically. ...
The net effect of the current rules is that the static matching requirement of 7.4(6/2) makes 7.4(7.1/2) completely redundant and unnecessary. Thus, the easiest fix is to delete 7.4(7.1/2).
However, it is clear that it was intended that the explicit null_exclusions would not have to match (as is the case for other cases, like renames). This also would be consistent with the handling of unconstrained subtypes.
Moreover, this is a useful capability. If a package declares a private type whose full type is an access type, a null exclusion would not be allowed on a deferred constant for the private type; but it still might make sense on the full constant definition.
for all of the these reasons, we chose to adjust 7.4(6/2).
!corrigendum 7.4(6/2)
Replace the paragraph:
Replace this case in the ACATS B-Test B740002.
No change needed.


Questions? Ask the ACAA Technical Agent