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.4 required=5.0 tests=BAYES_00,INVALID_DATE, UNRESOLVED_TEMPLATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6ec0e822a8924768 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-19 07:50:48 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!paladin.american.edu!auvm!EUROCONTROL.DE!wel Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: comp.lang.ada Message-ID: <9410191357.AA22801@eurocontrol.de> Date: Wed, 19 Oct 1994 14:57:25 +0100 Sender: Ada programming language From: Bob Wells #402 Subject: Re: C-Ada Import of struct's -- Help Comments: To: INFO-ADA%NDSUVM1.BITNET@vm.gmd.de Date: 1994-10-19T14:57:25+01:00 List-Id: G'day Dave, Your absolutely correct about the access type/object/address relationship. I forgot to add the use of a record rep clause on the structure itself. The record rep. clause is used to force all the record components into the seqence and location that you want. Dave, did you mean to include a record rep. clause aswell to force the location of the record components into that as "requested" by the C "world?" Otherwise LRM 13.4.6 takes over and lets the compiler "juggle" the components as it wants to. I agree that use of system.addresses and address clauses is much more portable. I also did not make clear that the Ada/C string I/F subprogram should take care of the conversions from and to the conventions in the C and Ada worlds. BTW It was actually creating these I/F subprograms while compiling under SunAda 1.0 where I had the problems of strings, created using an allocator on an access type, that had a STRING'FIRST value that was not 1! (I mentioned this on c.l.a last year). The worst case I had was a STRING'FIRST of 23! BTW This is no longer the case in 1.1. Robert Dewar is quite right that there is no defined requirement that "a C string must be null terminated." You will need to see what is happening with strings in your "C world" and then design your Ada/C string conversion subprogram to comply. I still stand by the use of the C wrapper program where the call to the actual updating function is made. Also in the use of a returned status value so that you can control your error handling/ reporting only in the Ada world. As an extension to Dave Emery's comments on access types possibly not containing an address I would be interested to know if any compilers actually don't use addresses for their access types. And for those compilers that don't, what do they use? > In my (long and painful) experience interfacing Ada and C, I've found > that the right approach is to bend over backwards and provide C with > the exact thing it asks for (e.g. the address of the first element of > a string is represented in Ada by STR(STR'FIRST)'ADDRESS). > Fortunately, we can use the features of Ada to hide this ugliness > within a package body, protecting the innocence of the programmer > using the package... BTW Dave, I totally agree with the above. Concerning the method of function parameter passing, I thought that "call by value" was strictly adhered to in C and that to achieve "call by reference" a pointer must be used? @ -------- @ //// ----- ( G'day! ) @ (o o) -------- @ ----oOO--(_)--OOo-------------------------------------------------------- Bob Wells "He looked at me as if I was a side dish he hadn't ordered." @ INTERNET: wel@eurocontrol.de CompuServe: 100272,3004 @ The Ada WWW Server is http://lglwww.epfl.ch/Ada/ Team Ada @ For exciting Ada info enter 'finger wel@s4ecawel.eurocontrol.de'