!standard 9.5(7.1/2) 11-02-19 AI05-0225-1/04 !class binding interpretation 10-10-21 !status work item 10-10-21 !status received 10-06-04 !priority Low !difficulty Easy !qualifier Omission !subject Call using constant protected objects !summary A protected procedure or entry of a protected constant cannot be called. !question 9.5(7.1) says, "The view of the target protected object associated with a call of a protected procedure or entry shall be a variable". Is it the intent that this be allowed? protected type Ptype is procedure P_Proc (Param1 : Integer); end Ptype; protected body Ptype is procedure P_Proc (Param1 : Integer) is begin ... end P_Proc; end Ptype; procedure Fool_The_Compiler (P_Obj : in Ptype) is -- P_Obj is constant type P_Proc_Acc is access protected procedure (Param1 : Integer); P_Acc : P_Proc_Acc; begin -- P_Obj.P_Proc (10); -- illegal by 9.5(7.1), but... P_Acc := P_Obj.P_Proc'access; -- (A) P_Acc (10); end Fool_The_Compiler; P_Obj.P_Proc'access is not a call, so it doesn't seem to be subject to the rule (see 6(2)). 9.5(7.1) cannot apply to the call P_Acc (10), since the "protected object associated with the call" is not known at compile time, and it can't be known statically whether the object is variable or constant. What is the intent here? (The 'Access attribute is illegal.) !wording Replace 9.5(2): Any call on an entry or on a protected subprogram identifies a *target object* for the operation, which is either a task (for an entry call) or a protected object (for an entry call or a protected subprogram call). The target object is considered an implicit parameter to the operation, and is determined by the operation name (or prefix) used in the call on the operation, as follows: with: Any name that denotes an entry or a protected subprogram identifies a *target object*, which is either a task (for an entry) or a protected object (for an entry or a protected subprogram). The target object identified by the operation name (or prefix) used in a call on an entry or a protected subprogram is considered an implicit parameter to the call. The target object is determined as follows: Replace 9.5(7.1/2): The view of the target protected object associated with a call of a protected procedure or entry shall be a variable. with: For a name that denotes a protected procedure, the view of the target object shall be a variable. For a name that denotes an entry, the view of the target object shall be a variable unless the name is the prefix of a reference to the Count attribute. AARM Note: The point is to prevent any calls to such a name, directly, or via an access value, renames, or generic formal subprogram. It is, however, legal to say P'Count in a protected function body, even though the protected object is a constant view there. !discussion This problem is similar to the one recently fixed for several restrictions, such as No_Specific_Termination_Handlers. There is no value in allowing the use of a name of a callable entity that would be illegal to call, for the reasons shown in the question. Thus we make such cases illegal. We need to cover the case of a selected component, as well as the case where the protected object is implicit (when we're inside it). We explicitly enumerate the cases we are trying to prevent. !ACATS Test An ACATS B-Test needs to be constructed to test examples like the one in the question (and others implied by the new rule). !ASIS No impact on ASIS. !appendix !topic Call using constant protected objects !reference 9.5(7.1) !from Adam Beneschan 10-06-04 !discussion 9.5(7.1) says, "The view of the target protected object associated with a call of a protected procedure or entry shall be a variable". Is it the intent that this be allowed? protected type Ptype is procedure P_Proc (Param1 : Integer); end Ptype; protected body Ptype is procedure P_Proc (Param1 : Integer) is begin ... end P_Proc; end Ptype; procedure Fool_The_Compiler (P_Obj : in Ptype) is -- P_Obj is constant type P_Proc_Acc is access protected procedure (Param1 : Integer); P_Acc : P_Proc_Acc; begin -- P_Obj.P_Proc (10); -- illegal by 9.5(7.1), but... P_Acc := P_Obj.P_Proc'access; P_Acc (10); end Fool_The_Compiler; P_Obj.P_Proc'access is not a call, so it doesn't seem to be subject to the rule (see 6(2)). I don't see how 9.5(7.1) can apply to the call P_Acc (10), since the "protected object associated with the call" is not known at compile time, and it can't be known statically whether the object is variable or constant. I don't actually see why *any* use of Constant_Protected_Object.Protected_Procedure or Constant_Protected_Object.Entry should be allowed; I can't think of a context where it could be useful. This includes not just 'access, but also subprogram renames and actuals for generic formal subprograms. Maybe I've missed some other places. But the way the rule is written, it applies only to calls and not other uses of the protected procedure or entry. **************************************************************** From: Randy Brukardt Sent: Monday, January 24, 2011 11:20 PM ... > !wording > > Add after 4.1.3(13.2/2): [Legality Rules] > > The name of a protected procedure or entry of a constant view > of a protected object is illegal in the following cases: the > name of a call, the prefix of an Access attribute, the name > of a subprogram_renaming_declaration, an > explicit_generic_actual_parameter, or the subprogram_default > of a formal_subprogram_declaration. This seems like an odd place for this rule, given that 4.1.3 is discussing selected components, but this rule covers some cases that have nothing to do with selected components. It would seem to make more sense to just replace the existing rule in 9.5(7.1/2) with this one. (We are deleting that rule anyway.) Or maybe there is a better place for this rule than either of these places?? **************************************************************** From: Bob Duff Sent: Monday, January 24, 2011 11:20 PM > This seems like an odd place for this rule, given that 4.1.3 is > discussing selected components, but this rule covers some cases that > have nothing to do with selected components. It would seem to make > more sense to just replace the existing rule in 9.5(7.1/2) with this > one. (We are deleting that rule > anyway.) Sounds good to me. >...Or maybe there is a better place for this rule than either of these >places?? Nah. ****************************************************************