!standard 4.6(24.21/4) 20-07-24 AI12-0387-1/01 !standard 6.1.1(0) !standard 13.1.1(17/5) !standard 13.1.1(18/4) !standard H.4(23.2/5) !standard H.4(23.3/5) !standard H.4(23.4/5) !standard H.7(0) !class Amendment 20-06-09 !status work item 20-06-09 !status received 20-06-08 !priority Low !difficulty Medium !subject Private_Global aspect !summary The Private_Global aspect is introduced. !problem We would like to give implementors some freedom in implementing language-defined package specs, including in the area of usage of global variables. Originally we thought we could allow implementors to add "in out synchronized" as needed, and presumed that there would be no impact on users of the package. Alas, that is not so simple if the user of the package is also interested in using Global aspects, because as currently defined, any global variable that a called routine uses must be reflected somehow in the Global aspect of the caller. This clearly can create a situation where a very small change deep within an implementation, to add a cache, for example, or some logging code, could have ripple effects throughout the implementation, and even worse, affect many of the existing clients. !proposal Ada has a strong separation between spec and body, and it makes sense to make a similar separation if possible in terms of global variable usage. Some global variable usage is relevant to the caller, and should not be hidden within the implementation. But other global variables are merely for caching, logging, or other caller-irrelevant purposes, and should not need to be reflected in the caller-visible Global aspect. We therefore propose to allow a Private_Global aspect on the body of a program unit, and on the body of a library unit as a default for program units completed within the library unit body, to specify global variable usage that is not relevant to the caller. The syntax would be identical as the Global aspect, and the sets of global variables that are allowed to be read or written by a given program unit would simply be the union of the Global and Private_Global aspect. At a subprogram call (or other invocation of a program unit), only the Global aspect of the invoked routine would be relevant to the caller, and would have to be covered by the union of the caller's Global and Private_Global aspects. Clearly Private_Global aspects should under normal circumstances be limited to globals that are not visible to the callers, and similarly should normally be synchronized, but we do not propose to limit that at this point. Implementations are permittted to enforce such restrictions, but for now we require only a simple capability of separating caller-relevant globals from those that are not of concern to the caller. The intent is that if two calls have the same caller-relevant inputs (i.e. Global variables and in [out] parameters), then they should return the same result in the caller-relevant outputs (i.e. Global variables and [in] out parameters). We allow implementations to detect and complain about such situations Similarly, we allow implementations to complain if two calls that would normally not conflict based strictly on the caller-relevant inputs and outputs would now conflict if the Private_Global aspects are considered. As usual, program execution would be erroneous if an actual data race occurs. !wording Modify H.7(1/5): H.7 Extensions to Global and Global'Class Aspects In addition to the entities specified in 6.1.2, the Global aspect may be specified for a subtype (including a formal subtype), formal package, formal subprogram, and formal object of an anonymous access-to-subprogram type. {The Private_Global aspect may be specified on bodies of program units for which a Global aspect is permitted on their specification. Private_Global follows the same syntax, name resolution, and legality rules as Global.} Modify H.7(2/5): The following additional syntax is provided for specifying Global{, Private_Global,} and Global'Class aspects, to more precisely describe the use of generic formal parameters and dispatching calls within the execution of an operation: Add after H.7(19/5): If a Private_Global aspect is specified on the body of a program unit, then within the body of the unit, the relevant global variable sets are each the union of those determined by the Global aspect with those determined by the Private_Global aspect. If a Private_Global aspect is not specified it defaults to that of the enclosing library unit body. If no Private_Global aspect is specified on the enclosing library unit body, then it is as though the Private_Global aspect were specified as NULL, meaning the subprogram is limited to the sets of global variables determined by the Global aspect on the specification. Add after H.7(22/5): Implementation Permissions An implementation may restrict the use of global variables identified by a Private_Global aspect applicable to the body of a program unit, if it can determine that the use of such a global variable would produce different results in two distinct invocations of the program unit, in terms of the IN OUT and OUT formal parameters and visible globals, given equivalent inputs in terms of the IN and IN OUT parameters and visible globals, where the /visible globals/ are those identified by an applicable Global aspect. Similarly, the implementation may restrict uses of such global variables if the usage could introduce a conflict with other actions occurring in other logical threads of control, if such a conflict would not otherwise exist. The possible consequences of violating such restrictions are implementation defined, and could include a compile-time error or the raising of Program_Error at run time. !discussion Rather than defining a Bounded Error if Private_Global usage could change the "visible" results, or introduce a conflict with another logical thread of control, we give the implementation permission to restrict such usage, with consequences that match those of Bounded Errors. We chose this approach because formally defining the circumstances for the bounded error is not practical given the difficulty of defining equivalence in inputs and outputs. We leave this area to implementations, while giving them permission to introduce compile-time or run-time restrictions that can provide additional safety guarantees. !example TBD !ASIS No ASIS effect. !ACATS test ACATS B-Tests are needed to check that the updated rules are enforced. !appendix ****************************************************************