Re: Interface to C; Storage_Error

["DuckE" <nospam_steved94@home.com>]

Here's my semi-educated "guess" at the interface to this function:

  package C renames Interfaces.C;

  subtype Srv_Handle is C.Unsigned_Long;         -- Assumes type for
"Handle" is Unsigned_Long
  type Ctx_Handle is access all C.Unsigned_Long; -- Assumes type for
"Ctx_Handle" is Unsigned_Long
  subtype Flt_Handle is C.C_Float;               -- Assumes type for
"Flt_Handle"

  function GetNextVal( srv : access Srv_Handle;
                       rslt : access Srv_Handle;
                       ctx  : access Ctx_Handle;
                       name : C.Char_Array;
                       dbl  : access C.Double;
                       flt  : access Flt_Handle ) return C.Int;
  pragma Import( C, GetNextVal );

Since the "C" prototype is using "char *" I suspect you need to allocate the
data to send to the
function.  I suspect a call would look something like:

-- (untested)
  srv : aliased Srv_Handle;
  rslt : aliased Srv_Handle;
  ctx : aliased Ctx_Handle;
  name : C.Char_Array := C.To_C( "Name" );
  dbl : aliased C.Double;
  flt : aliased Flt_Handle;
  result : C.Int;
begin
  result := GetNextVal( srv => srv'access,
                    rslt => rslt'access,
                    ctx => ctx'access,
                    name => name,
                    dbl => dbl'access,
                    flt => flt'access );

In my experience there is often more than one choice of how to interface to
C code.  I usually
stay away from System.Addres, although it is certainly valid to use, I
prefer to avoid it.

BTW: It was a challenge to interface to the RSLinx 'C' SDK, but I eventually
made my way
through it.

Also... beware of callbacks.  I'm not sure if GNAT behaves the same, but
with ObjectAda
if you are inside of a callback from a "C" library and you attempt to
perform an Ada tasking
operation (ie: Rendevous or Protected Operation) bad things happen.
Apparently the
Ada run time library (RTL) keeps additional task control block (TCB)
information for
Ada tasks.
  In these cases I have resorted to using OS primatives for implmented my
own rendevous.

I hope this helps,
SteveD

"Chris" <enderx12@my-deja.com> wrote in message
news:91ondg$lpu$1@nnrp1.deja.com...
> Hi, all... after a long hiatus in the C++ world, I'm finally getting a
> chance to do some more Ada work, at my own suggestion. The ability to
> write production-quality multithread code an order of magnitude faster
> in Ada might have something to do with it.
>
> Anyway, I'm having an irritating problem interfacing with a vendor C
> library. The relevant stuff:
>
>   typedef void* SRV_HANDLE;
>   typedef void* CTX_HANDLE;
>   typedef void* RSLT_HANDLE;
>   typedef void* FLT_HANDLE;
>
>    int GetNextVal(SRV_HANDLE srv, RSLT_HANDLE rslt, CTX_HANDLE *ctx,
>                   char* name, double* dbl, FLT_HANDLE flt);
>
> My take on it in Ada (GNAT 3.13p) is:
>
>    type Srv_Handle is new System.Address;
>    -- same for the other handles
>
>    procedure GetNextVal(Ret  : out int;
>                         Srv  : Srv_Handle;
>                         Rslt : Rslt_Handle;
>                         Ctx  : access Ctx_Handle;
>                         Name : out chars_ptr;
>                         Dbl  : access double;
>                         Flt : Flt_Handle);
>    pragma Import(C, GetNextVal);
>    pragma Import_Valued_Procedure(GetNextVal);
>
> Both Name and Dbl are supposedly set/alloc'd by the library. When I
> call this, it raises Storage_Error on the library call. I am totally
> stumped as to what to fix, or even where to look. Is my Ada declaration
> even remotely correct?
> Other suggestions?
>
>
> Many thanks.
>
> --chris
>
>
> Sent via Deja.com
> http://www.deja.com/