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 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,73975695cdfcb86f
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.227.230 with SMTP id sd6mr1345455pbc.8.1333798355169;
        Sat, 07 Apr 2012 04:32:35 -0700 (PDT)
Path: 
 r9ni28781pbh.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Dispatching callback handed over to C
Date: Sat, 07 Apr 2012 12:32:33 +0100
Organization: A noiseless patient Spider
Message-ID: <m2iphbhj5a.fsf@pushface.org>
References: <slrnjnl944.1lme.lithiumcat@sigil.instinctive.eu>
	<6fb83c74-b2a4-4ae8-9c89-d755b737198f@v22g2000vby.googlegroups.com>
	<slrnjnlpmo.1lme.lithiumcat@sigil.instinctive.eu>
	<85d1ad51-c02b-44fa-87b6-02aa1d8ba1b2@x17g2000vba.googlegroups.com>
	<jlfm35$ohb$1@munin.nbi.dk>
	<62246369-6b9f-4a96-9c67-fd1774c02e78@k24g2000yqe.googlegroups.com>
	<jli6n9$5up$1@munin.nbi.dk>
	<a236ccdb-e8b8-4b13-9e93-a2596f54ddcb@l7g2000vbw.googlegroups.com>
	<jll327$i0i$1@munin.nbi.dk>
	<slrnjo007l.1lme.lithiumcat@sigil.instinctive.eu>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="dFCm8HWntFqmDIilBLqEJQ";
	logging-data="7548"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+q55XPP9ljsMnc2QOtnJs8Zv3L2O9Xk2w="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin)
Cancel-Lock: sha1:nux64VKuWljIHrIah4nwZRqN5iA=
Content-Type: text/plain; charset=us-ascii
Date: 2012-04-07T12:32:33+01:00
List-Id: <comp.lang.ada>

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> On 2012-04-05, Randy Brukardt <randy@rrsoftware.com> wrote:
>> In particular, we're talking about the mapping of C to Ada here, and
>> not the underlying design of the C API (which is out of our control
>> anyway). The question is how to map "void *" to Ada?
>>
>> 1) Some convention C access type designating an appropriate Ada type.
>>
>> 2) Some convention C access type designating a dummy Ada type (use 
>> unchecked_conversion as needed on the real types).
>
> What I'm still struggling with is why do I have to settle for #2, or
> what is preventing me from going for #1?
>
>    type Callback_Access is access all Event_Callback'Class;
>    pragma Convention (C, Callback_Access);
>
> Using Callback_Access in a subprogram imported from C trigged the
> following GNAT warning:
>
>         >>> warning: "Imported_Subprogram.Arg" involves a tagged type
> which does not correspond to any C type
>
> I guess since it's "only" a warning, I could just silence. However I
> can't bring myself to silence something I don't understand.
>
> If it's only about the fact that Callback_Access is a C pointer to an
> object with which C subprograms has no way for dealing properly, then
> fine (since in that particular case C code considers it as an opaque
> pointer).

I think that must be it. I did wonder whether a classwide pointer might
be a fat pointer, but one would hope that in that case the compiler
would complain that pointer-to-classwide doesn't fit in a standard C
pointer.

I do seem to remember that, in a similar context - possibly context
parameters to Xt callbacks - a GNAT compiler managed to squeeze what was
normally a fat pointer into a thin one. It was a long time ago.

However, in this case GNAT uses thin (64-bit) pointers for both Ada and
C convention pointers (GCC 4.6.0, x86_64-apple-darwin10).