Version 1.2 of ais/ai-00397.txt

Unformatted version of ais/ai-00397.txt version 1.2
Other versions for file ais/ai-00397.txt

!standard 6.3.1(24.1/2)          05-01-25 AI95-00397/01
!standard 9.1(9.3/2)
!standard 9.1(9.8/2)
!standard 9.4(11.1/2)
!standard 9.4(11.6/2)
!standard 9.4(11.8/2)
!standard 9.5.2(2)
!standard 9.5.2(13)
!class amendment 05-01-25
!status work item 05-01-25
!status received 05-01-25
!priority High
!difficulty Easy
!subject Conformance rules and overriding indicators for entries and protected
operations
!summary
(See proposal.)
!problem
6.3.1(24/1) talks about subtype conformance of an entry and a subprogram, but an entry and a subprogram never have the same convention. Furthermore, it would seem that we would want the overriding indicators to be usable for entries and protected subprograms, even though they don't override anything (they implement the parent subprogram).
!proposal
Defined the term prefix profile to reduce the verbiage about "omitting the first parameter" and also to resolve the problem of convention matching. Replicated the wording from 8.3 about overriding indicators, with the simplification that we don't have to require that the entry/protected operation be a primitive operation. I put this with the definition of entries and protected subprograms, because it depends on "implemented" which is defined there. Putting it in 8.3 would have created a giant forward reference.
!wording
Replace 6.3.1(24.1/2) by:
The prefix profile of a subprogram is the profile obtained by omitting the first parameter of that subprogram. The prefix profile of a parameterless subprogram is not conformant with any entry or protected subprogram. For the purposes of defining subtype and mode conformance, the convention of a prefix profile is considered to match that of either an entry or a protected operation.
AARM Note: The weird rule about conventions is pretty much required for synchronized interfaces to make any sense. There will be wrappers all over the place anyway. Of course, this doesn't imply that entries have the same convention as protected operations.
Replace 9.1(9.3/2) by:
For a task_type_declaration, if the first parameter of a primitive inherited subprogram is of the task type or an access parameter designating he task type, and there is an entry_declaration for a single entry with the same identifier within the task_type_declaration, whose profile is type conformant with the prefix profile of inherited subprogram, the inherited subprogram is said to be implemented by the conforming task entry.
Replace 9.1(9.8/2) by:
o the inherited subprogram is implemented by a single entry of the task type; in which case its prefix profile shall be subtype conformant with that of the task entry.
Replace 9.4(11.1/2) by:
For a protected_type_declaration, if the first parameter of a primitive inherited subprogram is of the protected type or an access parameter designating the protected type, and there is a protected_operation_declaration for a protected subprogram or single entry with the same identifier within the protected_type_declaration, whose profile is type conformant with the prefix profile of the inherited subprogram, the inherited subprogram is said to be implemented by the conforming protected subprogram or entry.
Replace 9.4(11.6/2) by:
o the inherited subprogram is implemented by a protected subprogram or single entry of the protected type, in which case its prefix profile shall be subtype conformant with that of the protected subprogram or entry.
Add after 9.4(11.8/2):
If a protected subprogram declaration has an overriding_indicator, then:
o if the overriding_indicator is overriding, then the subprogram shall
implement an inherited subprogram, at the point of the declaration;
o if the overriding_indicator is not overriding, then the subprogram shall
not implement any inherited subprogram (at any point).
Change 9.5.2(2) to read:
entry_declaration ::= [overriding_indicator] entry defining_identifier [(discrete_subtype_definition)] parameter_profile;
Add after 9.5.2(13):
If an entry_declaration has an overriding_indicator, then:
o if the overriding_indicator is overriding, then the entry shall implement
an inherited subprogram, at the point of the declaration;
o if the overriding_indicator is not overriding, then the operation shall not
implement any inherited subprogram (at any point).
AARM Note: An entry family never implements anything, so only not overriding can be given on the declaration of a family.
!discussion
(See proposal.)
!example
--!corrigendum
!ACATS test
ACATS B-Test(s) should be created to check that overriding indicators are allowed and enforced here.
!appendix

****************************************************************

Questions? Ask the ACAA Technical Agent