Re: Interfacing to C library...

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Eric G. Miller" <egm2@jps-nospam.net> writes:

> Missed that addition since I was looking at a copy of original RM...

The version with all the Corrigendum AI's included is available on the
net somewhere.  Maybe somebody can post the URL?

> Anyway, I don't think the C_Pass_By_Copy semantics quite work the way I
> want them too (or, it's "kludgy").  All the "Set" routines of this C
> library take C structs by copy while all the "Get" routines take pointers
> and all routines return (in the function sense) a long integer status
> code.

Don't you mean the other way around?  I mean if you're Set-ing a field,
you would need a pointer in C.

>...  I've found if I use access types for the "Get" routines, then I 
> have to worry about aliasing and need to use T'Unchecked_Access or I
> need to dynamically create the objects via "new".

You can use access parameters instead of named access types,
and then you can say 'Access.  Either way, you better make sure the C
code doesn't squirrel away a copy of the pointer.

You can also pass a System.Address to the C routine, and use 'Address.
That's not *so* bad, if you encapsulate it inside a higher-level layer
that simply takes an 'in out' parameter, and uses exceptions to indicate
errors.

>...I think I like the
> GNAT Import_Function()/Import_Procedure() pragmas a little better, 
> since they facilitate finer control over the parameter passing method.
> However, I'd rather not use compiler specific capabilities... 

Good idea.  (At least *I* think portability to non-GNAT compilers is
good, in part because I work for SofCheck, which sells non-GNAT Ada
compilers.  ;-))

- Bob