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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!purdue!haven!uvaarpa!software.org!stluka
From: stluka@software.org (Fred Stluka)
Newsgroups: comp.lang.ada
Subject: Question about Ada renaming...
Message-ID: <1991Mar18.185344.16908@software.org>
Date: 18 Mar 91 18:53:44 GMT
Article-I.D.: software.1991Mar18.185344.16908
Sender: usenet@software.org (Usenet News/Mail Support)
Organization: Software Productivity Consortium, Herndon VA
List-Id: <comp.lang.ada>

Here is a question for the Ada gurus.

The Apollo (Verdix) Ada compiler accepts it;
the VAX Ada compiler reports errors at compile time.

Which is correct?

-----------------------------------

package aaa is 
    type int is new integer;
end;

with aaa;
package bbb is
    procedure proc (param : in out aaa.int);
end bbb;

with aaa;
with bbb;
procedure ccc is
    package a renames aaa;
    local_int : integer;
begin
    bbb.proc (aaa.int (local_int));   -- Works fine.
    bbb.proc (a.int (local_int));     -- Doesn't compile on VAX.
end ccc;

-----------------------------------

VAX Ada error messages:

Line  17:           bbb.proc (a.int (local_int));     -- Doesn't compile on VAX.
%ADAC-E-CONFDIFFNAME, Name a is not the same as aaa in bbb at line 7 [LRM 6.3.1]

Line  17:           bbb.proc (a.int (local_int));     -- Doesn't compile on VAX.
%ADAC-I-CONFWITHTYPEMAR, Error detected during conformance check with type mark 
        of subprogram 'in out' formal param in bbb at line 7

-----------------------------------

The referenced Ada RM section seems relevant.  To paraphrase:

     6.3.1(6)   Such conformance is required for type conversions
                used as actual parameters (see 6.4.1).

     6.4.1(3)   For a type conversion used as an actual parameter 
                of mode in out the type mark must conform (see 6.3.1)
                to the type mark of the formal parameter.

The heart of my question is:

     Should this usage (referring to the type mark via a renaming
     declaration) be considered a case of nonconformance?

If so, is there a way around this problem, other than the "Works fine"
line above, or a use clause?  This is abstracted out from a much more
complicated example in a large system where we use a standard set of
renames across the project.

--Fred
-- 

Fred Stluka                              Internet: stluka@software.org
Software Productivity Consortium         UUNET:    ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA