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:34:04 +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:48472 Date: 2017-10-14T19:34:04+03:00 List-Id: 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. 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! This way, what you have proposed is not a solution. I decided that I will remove allocator code (because it cannot be guaranteed to work) and (quote from my above message): --- Let the (C compatible) type of the struct be T. Using raptor_alloc_memory() allocate a void* pointer for an object of size 'Max_Size_In_Storage_Elements. Using some black magic () transform void* into an access to T. See https://groups.google.com/forum/#!topic/comp.lang.ada/-xfDsAOMj5s about the "black magic" to convert void* to an access. (I need to use 'Max_Size_In_Storage_Elements for allocation size to be sure assignment to my object won't overflow anything, right?) -- Victor Porton - http://portonvictor.org