From: Victor Porton <porton@narod.ru>
Subject: Re: Allocators design flaw
Date: Sat, 14 Oct 2017 19:38:08 +0300
Date: 2017-10-14T19:38:08+03:00 [thread overview]
Message-ID: <ortehn$j1$1@gioia.aioe.org> (raw)
In-Reply-To: lyd15pbtc9.fsf@pushface.org
Simon Wright wrote:
> Victor Porton <porton@narod.ru> writes:
>
>> As far as I understand, it will not work, because the C library I am
>> writing bindings for may try to free an object allocated by me (or I
>> my need to free an object allocated by the library).
>
> This vital info wasn't part of your original problem statement.
>
> I suppose you might just get away with creating a storage pool backed up
> by raptor_alloc_memory() (and corresponding free). But you'd have to
> cope with the alignment issue as Dmitry has suggested.
>
> Is the Ada side meant to understand things allocated on the C side? If
> so, you'll need to specify the representation exactly.
>
> Is the C side meant to understand things allocated on the Ada side?
> Likewise (and no room for hidden dope vectors!)
Yes, both sides need to understand struct layout.
This is not a trouble at all: I just add Convention=>C to the record.
We can know the alignment of the struct (just T'Alignment). The trouble is
that Ada may request allocator to allocate with alignment a (nonzero)
natural number times more than T'Alignment. This may fail as the requested
alignment in principle can be greater than the real alignment the C
*_alloc() function does. This is a real trouble.
--
Victor Porton - http://portonvictor.org
next prev parent reply other threads:[~2017-10-14 16:38 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-14 2:53 Allocators design flaw Victor Porton
2017-10-14 7:27 ` Dmitry A. Kazakov
2017-10-14 13:52 ` Victor Porton
2017-10-14 14:25 ` Dmitry A. Kazakov
2017-10-14 14:03 ` Victor Porton
2017-10-14 14:26 ` Dmitry A. Kazakov
2017-10-14 15:18 ` Victor Porton
2017-10-14 15:44 ` Dmitry A. Kazakov
2017-10-14 16:42 ` Victor Porton
2017-10-14 16:13 ` Simon Wright
2017-10-14 16:38 ` Victor Porton [this message]
2017-10-14 14:12 ` Victor Porton
2017-10-14 14:20 ` Victor Porton
2017-10-14 14:24 ` Victor Porton
2017-10-14 14:36 ` Dmitry A. Kazakov
2017-10-14 15:17 ` Victor Porton
2017-10-14 15:51 ` Dmitry A. Kazakov
2017-10-14 16:34 ` Victor Porton
2017-10-14 17:14 ` Dmitry A. Kazakov
2017-10-14 17:24 ` Victor Porton
2017-10-14 18:08 ` Dmitry A. Kazakov
2017-10-14 14:28 ` Dmitry A. Kazakov
2017-10-14 15:14 ` Victor Porton
2017-10-14 15:42 ` Simon Wright
2017-10-14 16:29 ` Victor Porton
2017-10-14 20:07 ` Simon Wright
2017-10-14 21:26 ` Victor Porton
2017-10-21 1:42 ` Randy Brukardt
2017-10-14 8:02 ` Simon Wright
2017-10-14 13:59 ` Victor Porton
2017-10-14 14:35 ` Simon Wright
2017-10-14 15:11 ` Victor Porton
2017-10-14 15:56 ` Simon Wright
2017-10-14 16:22 ` Victor Porton
2017-10-29 16:01 ` David Thompson
2017-10-14 14:11 ` Victor Porton
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox