Re: Allocators design flaw

[Victor Porton <porton@narod.ru>]

Dmitry A. Kazakov wrote:

> On 2017-10-14 18:34, Victor Porton wrote:
>> Dmitry A. Kazakov wrote:
>> 
>>> On 2017-10-14 17:17, Victor Porton wrote:
>>>> Dmitry A. Kazakov wrote:
>>>>
>>>>> On 2017-10-14 16:24, Victor Porton wrote:
>>>>>
>>>>>> I mean, it is because we cannot change C standard for better
>>>>>> compatibility with Ada. But we can change Ada 202x for better
>>>>>> compatibility with C libraries.
>>>>>
>>>>> There is nothing incompatible in what you described.
>>>>>
>>>>> There are many C libraries (most?) which cannot deal with objects
>>>>> allocated outside, e.g. in an Ada pool. There was never a big problem
>>>>> to communicate with such libraries.
>>>>
>>>> I want to create an Ada pool which does the same (de)allocation as a C
>>>> library.
>>>>
>>>> The problem is that creating such a pool is (seemingly) impossible with
>>>> current Ada RM.
>>>
>>> It is possible as I explained. You allocate additional information in
>>> front of the object and shift address. Upon deallocation you use that
>>> information to shift the address back before passing it to C's free. The
>>> same technique is used when handling Ada's array address issue in Simple
>>> Components.
>> 
>> Again:
>> 
>> You propose to allocate some additional data before value of a C struct
>> T.
>> 
>> But then I cannot pass the allocated pointer to C functions, instead I
>> pass the pointer + some shift value.
> 
> No. Address is passed to Ada.

The address is passed to Ada, but I also need to pass the pointer to C.

> There is no reason to pass any Ada pointers to any C functions except
> than in the form of "user data".

Convention=>C accesses to records ARE passed to C functions.

Sometimes we even don't know what is inside the records passed to C by a 
pointer.

Then we can use:

type Dummy_Record is null record with Convention=>C;

It is quite legit to pass (Convention=>C) pointers to Dummy_Record, and I do 
this a lot.

So your "There is no reason to pass any Ada pointers to any C functions" is 
wrong.

>> But C side may call a *_free() function on the passed pointer. If the
>> pointer after shifting is different than before shifting, then *_free()
>> would do a very wrong thing!
> 
> No it cannot. You cannot deallocate any Ada objects from C because they
> require finalization.

Convention=>C objects do not require finalization.

> A custom Ada storage pool backed by whatever C memory management library
> is perfectly possible even of C cannot handle alignment. As I explained
> Addresses are shifted forth and back between malloc-Allocate and
> Deallocate-free pairs.

See my other message. You do not understand me.

> Any other method of interaction is simply illegal because of
> finalization issues. If an object must be freed by C, it must a C
> object. If that is necessary, then for each C object an Ada object is
> created. See GtkAda for an example how such situations are handled.

-- 
Victor Porton - http://portonvictor.org