Version 1.1 of acs/ac-00074.txt

Unformatted version of acs/ac-00074.txt version 1.1
Other versions for file acs/ac-00074.txt

!standard 3.10 (09)          03-09-12 AC95-00074/01
!class amendment 03-09-12
!status received no action 03-09-12
!status received 03-08-15
!subject Aliased record components
!summary
!appendix

!topic Aliased record components
!reference RM95-3.10
!from Jeff Cousins 03-08-15
!keywords aliased
!discussion

Currently objects can be declared as aliased, but components of that object
are not aliased unless marked as such in the type declaration.
There thus appears to be some inconsistency as whether being aliased is a
property of an object or of a type.  The glossary in Annex N states the
former.

Take the following example:

package MY_REC_T_PKG is

   type NESTED_REC_T is record
     FIELD_1 : INTEGER;
     FIELD_2 : FLOAT;
   end record;

   type MY_REC_T is record
     HEADER : INTEGER;
     DATA   : NESTED_REC_T;
   end record;

end MY_REC_T_PKG;

with MY_REC_T_PKG;

procedure test2 is

   FIDDLE_ABLE_REC : aliased MY_REC_T_PKG.MY_REC_T;

   SAFE_REC        :         MY_REC_T_PKG.MY_REC_T;

   procedure PROCESS_MESSAGE (
     REC_PTR : access MY_REC_T_PKG.MY_REC_T) is
   begin

      null;

   end PROCESS_MESSAGE;

begin

   PROCESS_MESSAGE (FIDDLE_ABLE_REC'Access);

   PROCESS_MESSAGE (SAFE_REC'Access); -- Not allowed

end test2;

This behaves as I would expect.  Different objects of the same type can have
different aliased properties.


On the other hand...


with MY_REC_T_PKG;

procedure test3 is

   FIDDLE_ABLE_REC : aliased MY_REC_T_PKG.MY_REC_T;

   procedure PROCESS_DATA (
     REC_PTR : access MY_REC_T_PKG.NESTED_REC_T) is
   begin

      null;

   end PROCESS_DATA;

begin

   PROCESS_DATA (FIDDLE_ABLE_REC.DATA'Access);

end test3;

is not allowed though.  One has to edit the type definition, resulting in:

package MY_REC_T_PKG is

   type NESTED_REC_T is record
     FIELD_1 : INTEGER;
     FIELD_2 : FLOAT;
   end record;

   type MY_REC_T is record
     HEADER : INTEGER;
     DATA   : aliased NESTED_REC_T;
   end record;

end MY_REC_T_PKG;

with MY_REC_T_PKG;

procedure test4 is

   MAYBE_FIDDLE_ABLE_REC : MY_REC_T_PKG.MY_REC_T;

   procedure PROCESS_DATA (
     REC_PTR : access MY_REC_T_PKG.NESTED_REC_T) is
   begin

      null;

   end PROCESS_DATA;

begin

   PROCESS_DATA (MAYBE_FIDDLE_ABLE_REC.DATA'Access);

end test4;


This has several drawbacks:

It affects more places, whether or not an object can be manipulated indirectly
using an alias cannot be deferred until the object is declared but has to go in
its type definition;

It hides the fact that an object can be manipulated indirectly using an alias,
the word aliased could be hidden in another (possibly deeply nested) package.
Once any component of an object is vulnerable to fiddling with using an alias
then I think that the object as a whole should be regarded as vulnerable;

Different objects of the same type cannot have different aliased properties.

My thoughts are that declaring an object as aliased should allow any component
of that object to have 'access applied, and that declaring components of record
type definitions as aliased is undesirable.

****************************************************************

From: Tucker Taft
Sent: Monday, August 25, 2003  10:21 PM

Having "aliased" be inherited by all components
would create a number of difficulties.  First of
all, without "aliased" on the component definitions, the
components might not be aligned on addressible boundaries.
Second, because record and arrays types can be passed
by reference, one would have to assume that the actual
object (and thereby all its subcomponents) might be aliased, and
there might be pointers to individual components, making
optimization of any use of components of formal parameters
essentially impossible.

This comment seems to lack any compelling examples where
this capability would be of significant use, and it introduces
significant implementation and optimization difficulties.

****************************************************************

Questions? Ask the ACAA Technical Agent