From: Simon Wright <simon@pushface.org>
Subject: Re: Allocators design flaw
Date: Sat, 14 Oct 2017 16:42:17 +0100
Date: 2017-10-14T16:42:17+01:00 [thread overview]
Message-ID: <lylgkdbusm.fsf@pushface.org> (raw)
In-Reply-To: ort9le$1nrn$1@gioia.aioe.org
Victor Porton <porton@narod.ru> writes:
> The Ada problem is that that _alloc_memory() cannot be integrated with Ada
> allocators. The problem is that (in principle) Ada may request a greater
> alignment than C ever has, and this way Ada allocators become incompatible
> with C.
I just don't understand what the problem is.
If you declared an access type in Ada and invoked new, it's possible
(really only in the context of the AI I referenced earlier) that the
allocation might require an alignment greater than that required for the
basic data. The AI's first example is
type T is access String;
for T'Storage_Pool use ... ;
X : T := new String'("abc");
In the case of an access type whose designated subtype is an
unconstrained array subtype, some implementations prepend contiguous
dope information to the allocated array. String'Alignment is
typically 1. If the dope information contains values of the array
type's index type(s), then the alignment requirement of this dope
information might reasonably be that of the most strictly aligned
index type. The given example might be easier to implement if the
implementation were allowed to pass Integer'Alignment instead of
String'Alignment as the Alignment parameter in the call to Allocate
associated with the allocator.
If you then called Unchecked_Deallocation, it would need to be aware of
this extra dope information.
But you don't propose to invoke new, which means that
System.Storage_Pools.Allocate isn't going to be called. You're going to
get C to allocate the memory as appropriate for whatever it contains,
including any dope information, and if the Ada side gets to see its
contents it will do so via appropriate representation clauses, which
will explicitly include any dope information.
I agree that if the C side allocates the memory with an alignment that's
incompatible with the contents of the struct then you'll have a problem,
but I don't see how that could possibly be cured from the Ada side.
next prev parent reply other threads:[~2017-10-14 15:42 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
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 [this message]
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