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,UTF8
Received: by 10.68.74.201 with SMTP id w9mr2420585pbv.0.1333617190734;
        Thu, 05 Apr 2012 02:13:10 -0700 (PDT)
Path: 
 r9ni20826pbh.0!nntp.google.com!news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!217.73.144.44.MISMATCH!feeder.ecngs.de!ecngs!feeder2.ecngs.de!feeder.erje.net!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: Thu, 5 Apr 2012 09:13:10 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnjnqoga.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>
Mime-Version: 1.0
Injection-Date: Thu, 5 Apr 2012 09:13:10 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="Mda950WjNwNLAFOE7yJXQw";
	logging-data="4521"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+01VNzkeD2F5ckPkwRAkLx"
User-Agent: slrn/0.9.9p1 (FreeBSD)
Cancel-Lock: sha1:5kbwXu5Aht9/RrjJRfoIqWXM0gw=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Date: 2012-04-05T09:13:10+00:00
List-Id: <comp.lang.ada>

On 2012-04-04, Randy Brukardt <randy@rrsoftware.com> wrote:
> For instance, that's how we find the Ada object in Claw; we 
> unchecked-convert access-to-class-wide to a DWord in Windows, and then when 
> we need to use it, we unchecked-convert back. If I needed to make this 
> totally portable and had sufficient control over the API, I'd replace the 
> DWord by a locally-declared modular type of which I could control the size 
> to match the target. But there is little point in going further than that.
>
> System.Address is the wrong type to use for a "bucket-of-bits". I agree that 
> it would be nice to be able to directly put the access-to-class-wide in the 
> C convention record (and most compilers will in fact allow this, after 
> giving some warnings), but it doesn't seem to make that much difference.

So for my binding, what about something like :

   type Opaque_Data is null record;
   pragma Convention (C, Opaque_Data);

   type Opaque_Pointer is access all Opaque_Data;
   pragma Convention (C, Opaque_Pointer);

   type Callback_Access is access all Event_Callback'Class;
   pragma Convention (C, Callback_Access);

   procedure Set_C_Callback (<various arguments>;
                             Data : Opaque_Pointer);
   pragma Import (C, Set_C_Callback, "set_callback");


   procedure Called_From_C (<various arguments>;
                            Data : Opaque_Pointer)
   is
      package To_Ada is new Ada.Unchecked_Conversion
        (Source => Opaque_Pointer, Target => Callback_Access);

      Callback : Callback_Access := To_Ada (Data);
   begin
      Callback.all.Handle (<...>);
   end Called_From_C;

   pragma Convention (C, Called_From_C);


   procedure Set_Callback (<various arguments>;
                           Callback : in out Event_Callback'Class)
   is
      package To_C is new Ada.Unchecked_Conversion
        (Source => Callback_Access, Target => Opaque_Pointer);
   begin
      Set_C_Callback (<...>, To_C (Callback'Access));
   end Set_Callback;

As far as I cen tell, Opaque_Pointer refers only to types compatibles
with C, so the imports goes well and without warning, while
Opaque_Pointer and Callback_Access, being both access types with the
same convention, ensures they can be safely (in terms of keeping the
bit pattern intact, of course not type-safety) converted back and forth.

Or is there some trap in the above code that I'm missing?


Thanks for your help,
Natasha