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,FREEMAIL_FROM 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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: Victor Porton Newsgroups: comp.lang.ada Subject: Re: Allocators design flaw Date: Sat, 14 Oct 2017 19:29:32 +0300 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: 8U0x309/ia0QUzusgm/krA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: abuse@aioe.org User-Agent: KNode/4.14.10 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:48471 Date: 2017-10-14T19:29:32+03:00 List-Id: Simon Wright wrote: > Victor Porton 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"); The trouble is as follows: There is nothing in Ada standard to prevent the above "new" operator to request 256-byte alignment of the data. (Yes, I know this does not happen in practice, but it is not forbidden by the RM.) If it requests such a great alignment by the C function *_alloc_memory() is able to do only 16-byte alignment, then my allocator would break the contract, that is allocate with lesser alignment than requested. This could in principle lead to undefined behavior. > 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. The above quotation is unrelated. > If you then called Unchecked_Deallocation, it would need to be aware of > this extra dope information. Again unrelated. > But you don't propose to invoke new, which means that Why? I do propose to invoke new. > 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, What I want is to write Allocate in such a way that it could work calling the C allocating function. > 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. "C side" allocated memory compatible with every C struct. This is not the problem. The problem that Ada may request a greater (a natural number of times) alignment and the C function cannot do what Ada requests. -- Victor Porton - http://portonvictor.org