Re: Ada equivalent for C-pointer?

[Niklas Holsti <nobody@nowhere.fi>]

Martin Krischik wrote:
> Niklas Holsti wrote:
> 
> 
>>Martin Krischik wrote:
>>
>>>Pascal Obry wrote:
>>>
>>>
>>>
>>>>Nick Roberts <nick.roberts@acm.org> writes:
>>>>
>>>>
>>>>
>>>>>For example, if there is a C function defined thus:
>>>>>
>>>>>  int wibble(int *n);
>>>>>
>>>>>then in Ada you can declare:
>>>>>
>>>>>  function Wibble (Number: in out Interfaces.C.int);
>>>>>  pragma Import(C,Wibble,"wibble");
>>>>>
>>>>>and it should work. (Obviously, you must link the C functions in
>>>>>somehow.)
>>>>
>>>>I don't think so. Here Number will be passed by value, no? And you also
>>>>need the returned value ;)
>>>
>>>
>>>No all out and in out parameter are passed as pointer when pragma
>>>Import(C is used - thats unless you use C_Pass_By_Copy. I have written
>>>quite a lot of code interfaceing with C.
>>
>>But according to LRM B.3(68), for an "in out" parameter of an
>>*elementary* type (as here) the pointer that is passed to the C function
>>is a pointer to a *temporary copy* of the parameter (here Number), not a
>>pointer to the parameter itself. This may not be what the C function
>>expects.
> 
> 
> Interesting. I have to think about that. Question is if the optimizer is
> allowed to remove the copy.

Well, as Nick Roberts pointed out LRM B.3(68) is only implementation 
advice, so to copy, or not to copy, is up to the implementation.

>>For example, it would not make sense for "wibble" to save the 
>>pointer for later use.
> 
> 
> Well storing a pointer to a stack object is allways wrong.

No -- it's only wrong (in the sense of "does not work") to *use* such a 
pointer after the containing stack frame has returned. In this example, 
the stack frame that contains "Number" may exist for several calls of 
"wibble" or other C functions in the same library, and "wibble" might 
want to store the pointer somewhere (perhaps in an equally temporary 
data structure) for use by the other functions in the library. I've seen 
C libraries that do things like that, and it works, but of course it 
increases the risk that programming errors lead to use of invalid 
(dangling) pointers.

> If you want to
> store a pointer to the object neither "in out" nor "anomymous access" is
> appropiate - a "pool access" should be used instead. And the Ada interface
> should reflect that - if only to document propper use.

I agree that "pool access" is a better solution when the C routine 
stores the pointer for a "long" time.

-- 
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .