- 5.a
- Discussion: The list of requirements can be checked for, even if issues like intelligibility are not addressed.
- 6 ·
- Where compiler-generated run-time checks remain;
- 6.a
- Discussion: A constraint check which is implemented via a check on the upper and lower bound should clearly be indicated. If a check is implicit in the form of machine instructions used (such an overflow checking), this should also be covered by the documentation. It is particularly important to cover those checks which are not obvious from the source code, such as that for stack overflow.
- 7 ·
- An identification of any construct with a language-defined check that is recognized prior to run time as certain to fail if executed (even if the generation of run-time checks has been suppressed);
- 7.a
- Discussion: In this case, if the compiler determines that a check must fail, the user should be informed of this. However, since it is not in general possible to know what the compiler will detect, it is not easy to test for this. In practice, it is thought that compilers claiming conformity to this Annex will perform significant optimizations and therefore will detect such situations. Of course, such events could well indicate a programmer error.
- 8 ·
- For each reference to a scalar object, an identification of the reference as either "known to be initialized," or "possibly uninitialized," independent of whether pragma Normalize_Scalars applies;
- 8.a
- Discussion: This issue again raises the question as to what the compiler has determined. A lazy implementation could clearly mark all scalars as "possibly uninitialized", but this would be very unhelpful to the user. It should be possible to analyze a range of scalar uses and note the percentage in each class. Note that an access marked "known to be initialized" does not imply that the value is in range, since the initialization could be from an (erroneous) call of unchecked conversion, or by means external to the Ada program.
- 9 ·
- Where run-time support routines are implicitly invoked;
- 9.a
- Discussion: Validators will need to know the calls invoked in order to check for the correct functionality. For instance, for some safety applications, it may be necessary to ensure that certain sections of code can execute in a particular time.
- 10 ·
- An object code listing, including:
- 11 ·
- Machine instructions, with relative offsets;
- 11.a
- Discussion: The machine instructions should be in a format that is easily understood, such as the symbolic format of the assembler. The relative offsets are needed in numeric format, to check any alignment restrictions that the architecture might impose.
- 12 ·
- Where each data object is stored during its lifetime;
- 12.a
- Discussion: This requirement implies that if the optimizer assigns a variable to a register, this needs to be evident.
- 13 ·
- Correspondence with the source program, including an identification of the code produced per declaration and per statement.
- 13.a
- Discussion: This correspondence will be quite complex when extensive optimization is performed. In particular, address calculation to access some data structures could be moved from the actual access. However, when all the machine code arising from a statement or declaration is in one basic block, this must be indicated by the implementation.
- 14 ·
- An identification of each construct for which the implementation detects the possibility of erroneous execution;
- 14.a
- Discussion: This requirement is quite vague. In general, it is hard for compilers to detect erroneous execution and therefore the requirement will be rarely invoked. However, if the pragma Suppress is used and the compiler can show that a predefined exception will be raised, then such an identification would be useful.
- 15 ·
- For each subprogram, block, task, or other construct implemented by reserving and subsequently freeing an area on a run-time stack, an identification of the length of the fixed-size portion of the area and an indication of whether the non-fixed size portion is reserved on the stack or in a dynamically-managed storage region.
- 15.a
- Discussion: This requirement is vital for those requiring to show that the storage available to a program is sufficient. This is crucial in those cases in which the internal checks for stack overflow are suppressed (perhaps by pragma Restrictions(No_Exceptions)).