Why must access to unconstrained array statically match?

Why must access to unconstrained array statically match?

[paul williams]

Given the following code sample:
--------------------------------------------------------
package A is
    type An_Array is array (Positive range <>) of Integer;
    type An_Array_Ptr is access all An_Array;
    
    The_Array : aliased An_Array (1..10);
    The_Ptr : An_Array_Ptr := The_Array'Access;
end A;
--------------------------------------------------------
We get an error at compile time that says:

  "subtype of The_Array does not statically match
   designated subtype An_Array [RM_95 3.10.2(27)]"

RM95 3.10.2 says:
"...The view denoted by the prefix X shall satisfy the 
following additional requirements, presuming the expected 
type for X'Access is the general access type A: 
...
(27) ... if A's designated type is not tagged, then the 
type of the view shall be the same, and either A's 
designated subtype shall statically match the nominal 
subtype of the view, or the designated subtype shall be 
discriminated and unconstrained;"

Sorry for the length of this, but can anyone tell me why 
this is prohibited?  The designated subtype is 
unconstrained (An_Array), so why can't I get the pointer 
to an aliased view of a constrained variable?  Does this 
have something to do with the restriction on discriminated 
records that the rationale mentions "which ensures that we 
cannot apply the Access attribute to a component that 
might disappear"? I don't get the connection.

-- 
regards, paul

"making the complex simple, that's creativity!" - unknown

Re: Why must access to unconstrained array statically match?

[Robert Dewar]

Paul Williams asks about

  package A is
      type An_Array is array (Positive range <>) of Integer;
      type An_Array_Ptr is access all An_Array;

      The_Array : aliased An_Array (1..10);
      The_Ptr : An_Array_Ptr := The_Array'Access;
  end A;

Yes, this is indeed illegal. GNAT agrees with

  a.ads:6:31: object subtype must statically match designated subtype

As Paul found out, the RM referene is not much help, it just repeats
this rule in more elaborate language.

But Paul asks *why* this rule is here, and the answer is that there is
an expectation that pointers to unconstrained array types may in fact
always point to an array with a preceding descriptor containing the
bounds. The question is whether such bounds must be allocated for
all aliased objects. In this case, do you want the compiler allocating
bounds for The_Array.

Well some implementors were very worried about space, and really wanted
the answer to be no. So here's the deal, if the nominal subtype of a
variable is constrained, as in this case, then the compiler does NOT
have to allocate a descriptor, and so you cannot let a pointer point
at it. This is of course very dependent on the implementation model,
and for example with GNAT we would have no trouble allowing this.

However, a worried implementor spoke, and hence the rule. The work around
is a bit horrible:

  package A is
      type An_Array is array (Positive range <>) of Integer;
      type An_Array_Ptr is access all An_Array;

      The_Array : aliased An_Array := (1 .. 10 => 0);
      The_Ptr : An_Array_Ptr := The_Array'Access;
  end A;

Now the nominal subtype of The_Array is unconstrained, so the compiler must
allocate a descriptor, and the pointer is allowed (in RMese, the subtypes
now statically match, so all is well). There is no way to work around this
without initializing The_Array.

The more familiar form of this trap is

    X : aliased constant String          := "abcde";
    X : aliased constant String (1 .. 5) := "abcde";

Unlike the situation in Ada 83 where giving bounds on the left was redundant,
and we could regard the former as an abbrevation for the latter, these are
quite different in Ada 95. The first must allocate a descriptor and would
allow an "access all String" to point to it, the second would not.

So, another pitfall in Ada 95. BUT, and this is a very important but, like
most other similar pitfalls, the result is simply that a program you expected
to be legal is illegal. This is a whole lot safer than pitfalls where the
result is execution anomolies or chaos :-)