!standard D.7(2) 19-02-18 AI12-0290-1/04 !standard D.7(10.10/4) !class Amendment 18-10-11 !status Amendment 1-2012 18-11-21 !status WG9 Approved 22-06-22 !status ARG Approved 7-0-0 18-10-22 !status work item 18-10-11 !status received 18-08-09 !priority Low !difficulty Easy !subject Restriction Pure_Barriers !summary Add a new restriction Pure_Barriers. !problem The Ravenscar profile is too restrictive for some applications that still need to be able to make timing and storage analyses enabled by a profile such as Ravenscar. Thus an additional profile with weaker restrictions is introduced (see AI12-0291-1). That profile needs a weaker barrier restriction. !proposal The new Jorvik profile (defined in AI12-0291-1) does not specify Simple_Barriers. Instead, a new restriction Pure_Barriers is applied. In addition to simple Boolean local variables, the new restriction also allows more complex Boolean expressions. Although more expressive, these expressions are still limited in content so that side effects, exceptions, and recursion are impossible. Removing the possibility of side effects is particularly important because the language does not specify the number of times a given barrier is evaluated. Note that, in the Ravenscar profile, the Count attribute is only allowed within protected entry bodies, whereas the new Jorvik profile also allows the attribute in the entry barriers. !wording Add before D.7(2) [under the Static Semantics heading] A scalar expression within a protected unit is said to be *pure-barrier-eligible* if it is one of the following: - a static expression; - a name that statically denotes a scalar component of the immediately enclosing protected unit; - a Count attribute_reference whose prefix statically denotes an entry declaration of the immediately enclosing unit; - a call to a predefined relational operator or boolean logical operator (and, or, xor, not), where each operand is pure-barrier-eligible; - a membership test whose tested_simple_expression is pure-barrier-eligible, and whose membership_choice_list meets the requirements for a static membership test (see 4.9); - a short-circuit control form both of whose operands are pure-barrier-eligible; - a conditional_expression all of whose conditions, selecting_expressions, and dependent_expressions are pure-barrier-eligible; or - a pure-barrier-eligible expression enclosed in parentheses. Add after D.7(10.10/4) Pure_Barriers The Boolean expression in each protected entry barrier is pure-barrier-eligible. !discussion We make the definition of pure-barrier-eligible as close as possible to predicate-static, as they serve similar purposes. !corrigendum D.7(2) @dinsb The following @i@fas are language-defined: @dinss A scalar @fa within a protected unit is said to be @i if it is one of the following: @xbullet @xbullet that statically denotes a scalar component of the immediately enclosing protected unit;> @xbullet whose @fa statically denotes an entry declaration of the immediately enclosing unit;> @xbullet, @b, @b, @b), where each operand is pure-barrier-eligible;> @xbullet@fa is pure-barrier-eligible, and whose @fa meets the requirements for a static membership test (see 4.9);> @xbullet @xbullet all of whose @fas, @i@fas, and @i@fas are pure-barrier-eligible; or> @xbullet enclosed in parentheses.> !corrigendum D.7(10.10/4) @dinsa @xhang<@xterm The CPU aspect is specified for the environment task. No CPU aspect is specified to be statically equal to Not_A_Specific_CPU. If aspect CPU is specified (dynamically) to the value Not_A_Specific_CPU, then Program_Error is raised. If Set_CPU or Delay_Until_And_Set_CPU are called with the CPU parameter equal to Not_A_Specific_CPU, then Program_Error is raised.> @dinst @xhang<@xtermThe Boolean expression in each protected entry barrier is pure-barrier-eligible.> !ASIS [Not sure. It seems like some new capabilities might be needed, but I didn't check - Editor.] !ACATS test ACATS B- and C-Tests are needed to check that the new restriction is supported. !appendix !topic new tasking restriction for use with new tasking profile (Jorvik) !reference Ada 2012 D.7 !from Steve Baird, Pat Rogers 18-07-26 !keywords new tasking restriction (This is version /01 of the AI - Editor.) **************************************************************** From: Randy Brukardt Sent: Thursday, October 11, 2018 7:59 PM Some minor wording issues with this AI. (1) No !problem or !proposal. I used the !discussion as a !proposal, and added a few words pointing at AI12-0291-1 for the !problem. These I did in the original version. (2) We have: - a name that statically denotes a scalar component of the enclosing protected object; or This doesn't work if there is more than one enclosing protected object. At least, I think you mean only to allow components of the object that actual owns the barrier. Remember, this definition has to stand alone; it can't assume the other restrictions of Jorvik. So something like: pragma Restrictions (Pure_Barriers); protected type Outer is procedure Foo; private Outer_Component : Natural; end Outer; protected body Outer is procedure Foo is protected type Inner is entry Bar; private Comp : Natural; end Inner; protected body Inner is entry Bar when Outer_Component > 10 is -- (1) ... end Inner; begin ... end Foo; end Outer; I don't think you mean to allow the barrier at (1). This is easily fixed by adding "immediately" in front of enclosing. The following Count attribute rule has the same problem, with the same fix. Yes, this example is likely nonsense, but it's legal in the absence of the restriction. We have to worry about people writing nonsense in the Standard. (3) We also have: - a function_call whose function_name or function_prefix statically denotes a predefined equality operator, a predefined relational operator, a predefined logical operator, or a predefined logical negation operator and whose actual parameters, if any, are all pure barrier eligible expressions; or Two problems here. The first is that the initial part is long winded -- compare this to the similar rule for predicate-static: - a call to a predefined equality or ordering operator ... Moreover, this wording as written excludes infix calls (at a minimum, you'd need to use "function call" rather than the syntactic "function_call" to include them, but even that is through several levels of equivalence). I expect that Steve had something to do this with wording :-), and he's probably worried about the absence of "statically denotes" in the shorter wording. However, since predefined operators are intrinsic, they can't be passed or used as an access-to-subprogram value. In addition, while a formal subprogram can be passed a predefined operator, the formal subprogram itself is not a "predefined operator", so expressions in the generic unit would not be "pure barrier eligible" even if some instance might be. That would generally ban them in generic bodies anyway, and there are no barriers in specifications. Ergo, "a call" is OK here. (Not 100% sure of that in the predicate-static case, but I'm not going to answer a question not asked.) Additionally, we have "whose actual parameters, if any,". The next parameterless predefined operator that I encounter will be the first. So we can shorten this to "whose actual parameter(s)". Or, even better, we could use the same wording as predicate-static: - a call to a predefined equality operator, a predefined relational operator, a predefined logical operator, or a predefined logical negation operator, where each operand is a barrier eligible expression; (4) I don't understand "static Redundant[scalar] subtype" in the membership rule. If you mean to exclude string subtypes here, you'll need to say that. Specifically, without the supposedly redundant "scalar". the following is pure barrier eligible: protected type Stringy is entry Foo; private Label : String := ...; end Stringy; subtype Short_String is String(1..10); protected body Stringy is entry Foo when Label in Short_String is ... end Stringy; Actually, I don't see any particular reason to exclude this as it doesn't meet any of the reasons for exclusion: it can't raise an exception, nor does it have any chance of recursion. I suppose it isn't that useful. But if you do want to exclude it, it surely isn't "redundant" to do so; and if you don't really care, then the entire "redunant[scalar]" should be deleted. I don't know which one is appropriate. (5) Generally, in new bulleted lists, we only put the "or" on the penultimate bullet, so it would read normally if written all as a single paragraph. See this in predicate-static, for instance. We're not that consistent about it, so it's not surprising to see some other way in the RM (which is why I said "new" above). (6) You need to give the actual paragraph numbers for the insertions, not just handwave "somewhere in D.7 under Static Semantics" or even "insert alphabetically". I put Pure_Barriers immediately because Simple_Barriers (which appears to have been the intent), as some of these restrictions appear to be defined alphabetically, but nowhere near all of them. (No_Terminate_Alternatives should be second last, for instance.) I've made all of these changes (except that for (4), I made the minimum change of eliminating "redundant", perhaps more should be done as noted above) to version /02 of the AI. **************************************************************** From: Randy Brukardt Sent: Wednesday, November 21, 2018 9:17 PM Another "for the record" post. When trying to figure out the format of this wording, I noticed that there still are some extra words relative to the similar predicate-static definition. I removed those ('cause I don't have to decide whether "expression" is in the syntax font or the regular font if it doesn't appear at all :-), and ended up with the following: A scalar expression within a protected unit is said to be *pure-barrier-eligible* if it is one of the following: - a static expression; - a name that statically denotes a scalar component of the immediately enclosing protected unit; - a Count attribute_reference whose prefix statically denotes an entry declaration of the immediately enclosing unit; - a call to a predefined relational operator or boolean logical operator (and, or, xor, not), where each operand is pure-barrier-eligible; - a membership test whose tested_simple_expression is pure-barrier-eligible, and whose membership_choice_list meets the requirements for a static membership test (see 4.9); - a short-circuit control form both of whose operands are pure-barrier-eligible; - a conditional_expression all of whose conditions, selecting_expressions, and dependent_expressions are pure-barrier-eligible; or - a pure-barrier-eligible expression enclosed in parentheses. ****************************************************************