Re: Access and alias

[tmoran@bix.com]

>If the compiler DID use a different representation for the
>two, I would say your prescription would be quite wrong, there
>is absolutely no requirement in the RM for such conversions,
>and pragmatically it would be a bad idea to molest parameters
>in this way.

So the effect of a pragma import on a function's parameters
should not be to generate any code, but merely to check that the
parameters' types are "compatible" between the external language
and the Ada compiler?  For

  type Matrix is array(1 .. 10, 1 .. 5) of float;
  type pconstrained is access matrix;
  type List is array(integer range <>) of float;
  type punconstrained is access List;

  function cf(a : pconstrained; b : punconstrained) return float;
  pragma import(C, cf);

Gnat 3.12p NT does indeed generate a nice diagnostic
"type of cf.b does not correspond to C pointer".

But it gives no warning for

  function Trace(M : in Matrix) return float;
  pragma import(Fortran, Trace);

where of course Matrix is stored in one way in Ada and another
in Fortran.  Is this disparity just B.1(20)'s "The implementation
permits T as an L-compatible type" with Gnat permitting
Matrix but not punconstrained?

The other part of the post was:
>Is there also a requirement that it convert its idea of a
>System.Address into the called language's idea of an access value?

So the compiler should not convert System.Address to char *p,
but may either permit it or flag it as it sees fit,  with no
required relationship to whether their memory representations
match?