Rejecting a unit when a pragma's assumptions are not satisfied AI-00850/04 1 93-06-24 BI WA | !standard 02.08 (08) 93-06-24 AI-00850/04 !editor Antoine Bertier/Goodenough 90-11-21 !class binding interpretation 91-03-01 | !status approved by WG9 93-06-18 !status ARG-approved 91-03-01 (6-0-0) (pending editorial review) !status work-item 90-11-21 !status received 89-12-11 !references 83-01314 !topic Rejecting a unit when a pragma's assumptions are not satisfied !SUMMARY 93-03-29 A compilation unit may be rejected (and therefore not added to the library) if it does not comply with the restrictions or assumptions specified for a pragma that appears within it or within a unit on which it depends. The conditions under which such a unit will be rejected must be documented in appendix F. If an implementation does not detect the violation, execution of the program may be erroneous; conditions under which execution becomes erroneous must also be documented in appendix F. In any case, a legal unit must be accepted if such a pragma is omitted. !QUESTION 91-02-11 2.8(8) says: An implementation is not allowed to define pragmas whose presence or absence influences the legality of the text outside such pragmas. Furthermore, 2.8(9) says: A pragma (whether language-defined or implementation-defined) has no effect if its placement or its arguments do not correspond to what is allowed for the pragma. If a compilation unit is discovered to violate "what is allowed for" an implementation-defined pragma, must the unit nonetheless be added to the program library? Would rejecting the unit constitute an influence on the legality of the text in the sense of 2.8(8) even if the unit would be accepted if the pragma were not present? !RECOMMENDATION 93-03-29 A compilation unit may be rejected (and therefore not added to the library) if it does not comply with the restrictions or assumptions specified for a pragma that appears within it or within a unit on which it depends. The conditions under which such a unit will be rejected must be documented in appendix F. If an implementation does not detect the violation, execution of the program may be erroneous; conditions under which execution becomes erroneous must also be documented in appendix F. In any case, a legal unit must be accepted if such a pragma is omitted. Rejecting a unit when a pragma's assumptions are not satisfied AI-00850/04 2 93-06-24 BI WA !DISCUSSION 93-03-29 Implementation-defined pragmas are often the only way for the user to make assertions on the intended behavior, structure, or use of a compilation unit. These assertions may allow an implementation to provide specific optimizations that would not otherwise be allowed, or they may merely reflect an intended coding style. A violation of any of these assertions is intended to be considered a user error. It is helpful to reject a compilation unit when such an error is detected so the user can correct the error either by removing the pragma or by changing the code to conform to the pragma's restrictions. Allowing a compilation unit to be rejected for such reasons may seem to be a radical change from 2.8(8-9). However, 2.8(8) mainly serves to disallow pragmas that affect the structure of source code (e.g., pragma INCLUDE). Pragmas that just assert specific properties of the text outside the pragma such as: pragma I_CLAIM_THIS_TASK_IS_PASSIVE(a_task_or_task_type); -- Typical restrictions could be: -- + no entry call outside of an accept statement -- + no dynamic creation via allocator -- + ... pragma WARN_ME_IF_I_HEAP_ALLOCATE; -- Typical restrictions could be: -- + no explicit nor implicit use of the heap are not disallowed even if they cause a compilation unit to be rejected when the associated restrictions are not satisfied. Such pragmas do not affect the LEGALITY of the text since the text satisfies Ada's legality rules when the pragma is removed. Another allowed kind of pragma makes an assertion that allows an implementation to make an optimization that would be invalid if the assertion were violated, e.g., a pragma indicating that a subprogram is not called recursively. Such a pragma is allowed since it does not affect the legality of the text. Of course, if an implementation can detect that the restriction implied by the pragma is violated, it can reject the unit that violates the restriction. (Note that in this case, the unit might be a unit that does not even contain the pragma but that instead, contains a call that completes a recursive chain of calls.) If the implementation does not detect a violation of such a restriction, execution of the program may well be erroneous.