Chapter 7: Portability - TOC - 7.1 FUNDAMENTALS

7.1.8 Dependence on Parameter Passing Mechanism

guideline

Do not write code whose correct execution depends on the particular parameter passing mechanism used by an implementation (Ada Reference Manual 1995, §6.2; Cohen 1986).

If a subprogram has more than one formal parameter of a given subtype, at least one of which is [in] out, make sure that the subprogram can properly handle the case when both formal parameters denote the same actual object.

example

The output of this program depends on the particular parameter passing mechanism that was used:

------------------------------------------------------------------------
with Ada.Integer_Text_IO;
procedure Outer is
   type Coordinates is
      record
         X : Integer := 0;
         Y : Integer := 0;
      end record;
   Outer_Point : Coordinates;
   ---------------------------------------------------------------------
   procedure Inner (Inner_Point : in out Coordinates) is
   begin
      Inner_Point.X := 5;
      -- The following line causes the output of the program to
      -- depend on the parameter passing mechanism.
      Ada.Integer_Text_IO.Put(Outer_Point.X);
   end Inner;
   ---------------------------------------------------------------------
begin  -- Outer
   Ada.Integer_Text_IO.Put(Outer_Point.X);
   Inner(Outer_Point);
   Ada.Integer_Text_IO.Put(Outer_Point.X);
end Outer;
------------------------------------------------------------------------

If the parameter passing mechanism is by copy, the results on the standard output file are:

0 0 5

If the parameter passing mechanism is by reference, the results are:

0 5 5

The following code fragment shows where there is a potential for bounded error when a procedure is called with actual parameters denoting the same object:

procedure Test_Bounded_Error (Parm_1 : in out    Integer;
                              Parm_2 : in out Integer) is
   procedure Inner (Parm : in out Integer) is
   begin
      Parm := Parm * 10;
   end Inner;
begin
   Parm_2 := 5;
   Inner (Parm_1);
end Test_Bounded_Error;

In executing the procedure Test_Bounded_Error, both Parm_1 and Parm_2 denote the object Actual_Parm. After executing the first statement, the object Actual_Parm has the value 5. When the procedure Inner is called, its formal parameter Parm denotes Actual_Parm. It cannot be determined whether it denotes the old value of Parm_1, in this case 1, or the new value, in this case 5.

Actual_Parm : Integer := 1;
. . .
Test_Bounded_Error (Actual_Parm, Actual_Parm);  -- potential bounded error

rationale

Certain composite types (untagged records and arrays) can be passed either by copy or by reference. If there are two or more formal parameters of the same type, one or more of which is writable, then you should document whether you assume that these formal parameters do not denote the same actual object. Similarly, if a subprogram that has a formal parameter of a given subtype also makes an up-level reference to an object of this same type, you should document whether you assume that the formal parameter denotes a different object from the object named in the up-level reference. In these situations where an object can be accessed through distinct formal parameter paths, the exception Program_Error may be raised, the new value may be read, or the old value of the object may be used (Ada Reference Manual 1995, §6.2).

See also Guideline 8.2.7.

exceptions

Frequently, when interfacing Ada to foreign code, dependence on parameter-passing mechanisms used by a particular implementation is unavoidable. In this case, isolate the calls to the foreign code in an interface package that exports operations that do not depend on the parameter-passing mechanism.