From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Allocators design flaw
Date: Sat, 14 Oct 2017 16:42:17 +0100
Organization: A noiseless patient Spider
Message-ID: <lylgkdbusm.fsf@pushface.org>
References: <orru6n$1hak$1@gioia.aioe.org> <orse8j$d7d$1@gioia.aioe.org>
	<ort609$1i31$2@gioia.aioe.org> <ort6u9$1iul$3@gioia.aioe.org>
	<ort9le$1nrn$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="e53c3a1e14119dea7f561d1d98279ae1";
	logging-data="18440"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19YZh9u37RXfBHbzYDzd9oiDRTSBV17jPA="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin)
Cancel-Lock: sha1:Ut5VC8W04MUAogDUZmxk6URTwR0=
	sha1:XMGhfHPcjIS/HMSdCAPUNC29VDI=
Xref: news.eternal-september.org comp.lang.ada:48465
Date: 2017-10-14T16:42:17+01:00
List-Id: <comp.lang.ada>

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.