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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.157.11.124 with SMTP id p57mr25898068otd.0.1462220050462; Mon, 02 May 2016 13:14:10 -0700 (PDT) X-Received: by 10.157.59.34 with SMTP id z31mr389869otb.16.1462220050402; Mon, 02 May 2016 13:14:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!sq19no1668263igc.0!news-out.google.com!k10ni57igv.0!nntp.google.com!sq19no1668262igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 2 May 2016 13:14:10 -0700 (PDT) In-Reply-To: <45cb9b19-b470-4649-843a-7b9f88411e6e@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=213.108.152.51; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 213.108.152.51 References: <45cb9b19-b470-4649-843a-7b9f88411e6e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2b4f1206-dea3-4cf5-9a6b-b857470dfb34@googlegroups.com> Subject: Re: A suggestion about interfacing with C From: Maciej Sobczak Injection-Date: Mon, 02 May 2016 20:14:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30339 Date: 2016-05-02T13:14:10-07:00 List-Id: > * others? >=20 > What would you suggest? Apart from the suggestions that you have got already, I would like to expan= d a bit on the "others" category. Note that in the case of this library (and many others, because the pattern= is popular) it is not necessary to pass the pointer to Ada, even if it is = opaque, as Ada will not operate on it. The only purpose of passing it to Ad= a is to pass it back to C, where the actual operations will take place, in = which case you might as well not pass it at all and just keep it at the C s= ide. Really, you do not need this value (no matter how mangled) at the Ada = level. And this observation opens the idea to pass some token instead (if t= here can be many objects identified this way), which might be of some more = Ada-friendly type, even (or maybe in particular) the integer. That is, you = can use 32-bit Integer on the Ada side, as a descriptor for the 64-bit poin= ter at the C side, and there is no need to pass the pointer around. You will need some additional, very thin layer of C to map one to another (= note that I used the word "map" instead of "convert"), but such a thin laye= r could prove useful anyway, in order to flatten and "sanitize" anything el= se that might need to be passed between domains. If there are any structs o= r #defines used in the C API, then you will find such a thin wrapper very v= aluable (how about checking whether the Ada descriptor is still valid, befo= re doing anything with the pointer?). The target is a C API that uses *only= * those types that are trivial to handle at the Ada level, where you can st= ack up higher-level APIs if necessary. I have used this approach to create bindings for both C and C++ libraries. --=20 Maciej Sobczak * http://www.inspirel.com