AI22-0114-1
!standard A.7(6) 24-11-03 AI22-0114-1/02
!standard A.8.2(4)
!standard M.3(82/3)
!class Binding Interpretation 24-08-09
!status Amendment 1-2022 24-11-01
!status WG9 Approved 25-07-18
!status ARG Approved 15-0-0 24-10-31
!status work item 24-08-09
!status received 24-08-02
!submitter John Barnes
!priority Low
!difficulty Easy
!qualifier Error
!subject “Main program” is not a defined term
Uses of “main program” in the Standard are changed:
AARM 10.2(34.f) explains that we do not use or define the term “main program”. We either should be referring to just the “program” (as a whole), or to the “main subprogram”.
But there are a few uses of “main program” remaining in this Standard. These should be fixed appropriately.
Replace “main program” with “main subprogram” or “program” or “partition” as appropriate.
Modify A.7(6):
The language does not define what happens to external files after the completion of the main {subprogram}[program] and all the library tasks (in particular, if corresponding files have not been closed). The effect of input-output for access types is unspecified.
Modify A.8.2(4):
A null string for Name specifies an external file that is not accessible after the completion of the {partition}[main program] (a temporary file). A null string for Form specifies the use of the default options of the implementation for the external file.
{AARM Ramification: Temporary files become inaccessible after the termination of the environment task of the partition (which includes the termination of any library tasks). If a program consists of multiple partitions, we do not require the temporary files to remain until all partitions have terminated, as that could require significant overhead for a rarely used feature of Ada.}
Modify M.3(82/3):
If Export is supported for a language, the main {subprogram}[program] should be able to be written in that language. Subprograms named "adainit" and "adafinal" should be provided for elaboration and finalization of the environment task. See B.1(39/3).
The correction to A.8.2(4) is not obvious. It doesn’t make sense to say “after the completion of the main subprogram”, as a library task could still be running and using a temporary file. That file needs to remain accessible until the library task completes. Compare the wording in A.8.2(4) with that of A.7(6), which explicitly mentions library tasks (and thus changing “main program” to “main subprogram” is clearly the correct change).
We could simply say “program”, but that could require overhead in the case that a program consists of multiple partitions. The partitions would have to somehow communicate which one completes “last” in order to know when to remove/preserve the temporary files. We don’t want to require making the implementation of partitions more complex for this rarely-used feature. Moreover, some target systems provide a form of temporary file management, and we want to be able to use those even when a program includes multiple partitions. So we want to use the conservative choice.
Thus, we want to use a similar meaning to that of A.7(6). But the wording of A.7(6) seems like a long-winded way of saying “partition” (or to be pedantic, the “termination of the environment task of the partition”). So we just say “partition”.
We consider that the model is that a temporary file belongs to the partition that created it, and should not exist after that partition has ended. This model is potentially incompatible, but it is not practically so, as the use of multiple partitions is rare, the use of temporary files is rare, and (since temporary files don’t necessarily have names) it is not possible to portably determine when the temporary files disappear. So no implementation needs to change because of this rewrite.
M.3(82/3) is easy: this is the summary of an Implementation Advice item, and the original item uses “main subprogram”. It is bizarre that the summary does not, it obviously should.
@drepl
The language does not define what happens to external files after the completion of the main program and all the library tasks (in particular, if corresponding files have not been closed). The effect of input-output for access types is unspecified.
@dby
The language does not define what happens to external files after the completion of the main subprogram and all the library tasks (in particular, if corresponding files have not been closed). The effect of input-output for access types is unspecified.
@drepl
A null string for Name specifies an external file that is not accessible after the completion of the main program (a temporary file). A null string for Form specifies the use of the default options of the implementation for the external file.
@dby
A null string for Name specifies an external file that is not accessible after the completion of the partition (a temporary file). A null string for Form specifies the use of the default options of the implementation for the external file.
@drepl
If Export is supported for a language, the main program should be able to be written in that language. Subprograms named "adainit" and "adafinal" should be provided for elaboration and finalization of the environment task.
@dby
If Export is supported for a language, the main subprogram should be able to be written in that language. Subprograms named "adainit" and "adafinal" should be provided for elaboration and finalization of the environment task.
Detecting when the temporary files are removed (“become inaccessible”) is not necessarily possible (the file may not have a usable name to check), and doing so in the case of a partitioned program would be a test combining two lesser used features. So this does not seem to be an appropriate ACATS test. A.7(6) is describing unspecified (thus untestable) behavior, and M.3(82/3) is describing advice (whether or not advice is followed is outside of the mandate of the ACATS). So no ACATS tests are needed here.