From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,3e5147bcbe0e25dc,start
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!postnews.google.com!q40g2000cwq.googlegroups.com!not-for-mail
From: msimonides@power.com.pl
Newsgroups: comp.lang.ada
Subject: Access to interface conversion problem
Date: 13 Mar 2007 08:25:09 -0700
Organization: http://groups.google.com
Message-ID: <1173799509.497206.119820@q40g2000cwq.googlegroups.com>
NNTP-Posting-Host: 62.111.211.178
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
X-Trace: posting.google.com 1173799514 24931 127.0.0.1 (13 Mar 2007 15:25:14
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 13 Mar 2007 15:25:14 +0000 (UTC)
User-Agent: G2/1.0
X-HTTP-UserAgent: Opera/9.02 (X11; Linux i686; U; en),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: q40g2000cwq.googlegroups.com; posting-host=62.111.211.178;
   posting-account=YHdqRw0AAAAIPYzcJprg4QGlRlBwcPu_
Xref: g2news1.google.com comp.lang.ada:14510
Date: 2007-03-13T08:25:09-07:00
List-Id: <comp.lang.ada>

I have experienced problems upon using an access to tagged type object
converted to an access to ancestor type - Storage_Error is raised when
calling its operations.

After some investigation I found out that address of object (obtained
like this: Object_Ptr.all'Address) is different after conversion.
Using Unchecked_Deallocation for converting the access value solved
the problem.

The situation is analogous to that in program below:

with System.Address_Image; use System;
with Ada.Text_IO; use Ada.Text_IO;

procedure IFace_Cast_Bug is

   type Root_Type is interface;
   type Root_Access is access all Root_Type'Class;

   type Additional_Operations_Type is interface and Root_Type;
   type Additional_Operations_Access is access all
      Additional_Operations_Type'Class;

   type Root_Implementation_Type is new Root_Type with null record;
   type Root_Implementation_Access is access all
      Root_Implementation_Type'Class;

   type Final_Implementation_Type is new Root_Implementation_Type and
      Additional_Operations_Type with null record;
   type Final_Implementation_Access is access all
      Final_Implementation_Type'Class;


   function To_Additional_Operations (Object_Ptr :
Final_Implementation_Access)
      return Additional_Operations_Access
   is
   begin
      return Additional_Operations_Access (Object_Ptr);
   end To_Additional_Operations;


   Object_Ptr  : constant Final_Implementation_Access :=
      new Final_Implementation_Type;

   Iface_Ptr   : constant Additional_Operations_Access :=
      To_Additional_Operations (Object_Ptr);
begin
   Put      (Address_Image (Object_Ptr.all'Address));
   Put      (" /= ");
   Put_Line (Address_Image (IFace_Ptr.all'Address));
end IFace_Cast_Bug;

The output of this program is two addresses, the first one 4 less than
the second one (in my original program the difference is 12).
Removing the Root_Implementation_Type tagged type from inheritance
hierarchy results in identical addresses.

The question is:
Am I doing something wrong with the conversion? I believe that
upcasting should be perfectly safe and operations defined for the
target type should work on the access (and even incorrect downcast
should raise Constraint_Error instead of a Storage_Error postponed to
the first use).

To me this looks like a compiler bug.

I am using GNAT GPL 3.4.6 on Linux.
--
Marcin Simonides