Re: Array access via pointer?

["Robert I. Eachus" <rieachus@earthlink.net>]

Ken Garlington wrote:
 
> No, you don't have to allocate the arrays in the heap -- so long as you're
> willing to accept the risks of converting a System.Address to an access
> type! (For the specific example I gave, the risks appear to be low in my
> experience.)

   And my experience has been quite the opposite!  If your only use of
the 'trick' is to convert the address of an object to an access value
designating the object, it will usually work.  In general in Ada 95 the
address of an array object should be the address of the first element:

   "For an array X, X'Address should point at the first component of the
array,
and not at the array bounds."  RM 13.3(14)

   The first thing to note about the paragraph quoted above is that this
is in a section titled, "Implementation Advice."  Of course, most
compilers do follow this advice.  However, if you pass in the address of
a component of the array, other than the first, things will often go
wrong.  Some compilers implement the above advice by storing any
necessary descriptor data at a negative offset from the address, which
is probably deadly in the case under discussion.  Other compilers do
this by materializing the descriptor data where necessary and, if
necessary  by passing additional 'hidden' parameters as part of calls
with parameters of the array base type, whether or not the parameter
subtype is actually constrained.  In this case, if you don't materialize
the data in an Ada array, the compiler has no place to go to find the
attributes it needs to create the call. Often this means that you need
an object, sometimes a constant object, which has the correct
attributes.  You then can use an attribute definition clause to say that
the object is located at the address of the actual data.  Remember that
in Ada you can have a nested declare block--or even a procedure or
function--that declares both the subtype bounds and the address
differently each time it is entered:

    procedure Map_Array(Addr: in System.Address; First, Last: in
Integer) is
      Temp: My_Array_Type(First..Last);
      for Temp'Address use Addr;
    begin
      Some_Stuff;
      -- in here it is safe to treat the data as an Ada array,
      -- assuming all the parameters are correct.
    end Map_Array;

    You can even make Map_Array a generic procedure with a subprogram
parameter,
and use it to apply different actions to the array.  Sound complex? 
Actually this approach to interfacing to hardware or other programming
languages can get much hairier.  If you are interfacing to actual
hardware registers or to code running in another thread, you may also
need to specify pragmas Atomic, Atomic_Components, Volatile or
Volatile_Components.  Figuring out which you may need is a non-trivial
exercise, and is common to all interfaces no matter how they are
declared.

   The right solution, at least to the interfacing problems is to use
Annex B.  After all that is what it is there for.  In this particular
example, the package Interfaces.C.Pointers may be just what the doctor
ordered.  Again, though, if you are interfacing to hardware or to
another thread or process, watch it.  It is up to you to warn the Ada
compiler what the other guy is doing using the above pragmas.