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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no 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 sd6mr1035590pbc.8.1333788949852;
        Sat, 07 Apr 2012 01:55:49 -0700 (PDT)
Path: 
 r9ni28378pbh.0!nntp.google.com!news1.google.com!goblin2!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Dispatching callback handed over to C
Date: Sat, 7 Apr 2012 08:55:49 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnjo007l.1lme.lithiumcat@sigil.instinctive.eu>
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>
Mime-Version: 1.0
Injection-Date: Sat, 7 Apr 2012 08:55:49 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="Mda950WjNwNLAFOE7yJXQw";
	logging-data="30375"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+oXh6u3kyzGZtTMx8laPT+"
User-Agent: slrn/0.9.9p1 (FreeBSD)
Cancel-Lock: sha1:Ih7nOOElCdbRKPHOh47nETti9vs=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: 2012-04-07T08:55:49+00:00
List-Id: <comp.lang.ada>

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).

However it's worded like "warning: you're mixing C and Ada", to which
I'm tempted to answer "breaking news ! writing a binding involves mixing
two languages", but that would be rude and there is no point in telling
a compiler things in a human language anyway.

On the other hand, solution #2 allows the import package to not know
about Event_Callback type, and potentially be used with other Ada
callback implementation.


Thanks for your insights,
Natasha