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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1fd537a3da8a5021 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Array access via pointer? Date: 2000/08/04 Message-ID: <398A1B77.A2A3D302@earthlink.net>#1/1 X-Deja-AN: 654253455 Content-Transfer-Encoding: 7bit References: <398721AD.CAEE3A51@home.com> <8m7hn1$i4r$1@nnrp1.deja.com><3988269B.D1DB4EA5@home.com> <813i5.1869$SB4.159422@news.flash.net> <8ami5.2464$SB4.219190@news.flash.net> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 965352260 63.24.57.193 (Thu, 03 Aug 2000 18:24:20 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Thu, 03 Aug 2000 18:24:20 PDT Newsgroups: comp.lang.ada Date: 2000-08-04T00:00:00+00:00 List-Id: 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.