Re: Importing C structs?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Matthew Heaney wrote:
> Ching Bon Lam <c.lam_REMOVE_THIS@student.utwente.nl> wrote in message news:<Xns93C98A38494B8cblamstudentutwenten@194.109.133.20>...
> 
>>"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in
>>news:1V1Wa.299$jp.55@newsread4.news.pas.earthlink.net: 
>>
>>>This is probably overkill.  For an opaque type all you need to do is:
>>>
>>>type DB_Type is limited null record;
>>>type DB_Access is access all DB_Type;
>>>for DB_Access'Storage_Size use 0;
>>>pragma Convention (C, DB_Access);
>>
>>overkill? i don't think so.. opaque_structure_def is defined in 
>>Interfaces.C.Extensions (i-cexten.ads in gnat) as:
>>
>>subtype opaque_structure_def is System.Address;
>>
>>just a memory address. That's the same as DB *. Since the api (well, most 
>>api written in C) only use DB * and not DB, you don't need another access 
>>type. that's why 
> 
> A memory address is not the same thing as DB*.  A "memory address" has
> type void*.  A void* can point to anything.  A DB* can not.
> 
> You are free of course to use System.Address everywhere in Ada, just
> as you are free to use void* everywhere in C, but you lose strong
> typing that way.  There is a reason why the C API used type DB* and
> not type void*.
> 
> So I stand by my assertion that type opaque_structure_def is not the
> correct choice for a binding to dbopen().

 From what I have seen in this thread, this "project"
should be a "binding" so that these types of entities are
not directly used by a client program.

In this way, you can carry DB* arround any way that makes
sense, as long as it is properly preserved internally
(perhaps in an Ada tagged record), and nulled
when it is invalid to reference it.

Sometimes within a binding, an external entity's precise makeup
cannot be [conveniently/portably] known. But if you only need
to reference it, then this is no hardship. You then only have
to properly manage its use.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg