From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a37:624a:: with SMTP id w71mr7825871qkb.81.1631664701780; Tue, 14 Sep 2021 17:11:41 -0700 (PDT) X-Received: by 2002:a25:b782:: with SMTP id n2mr2463284ybh.159.1631664699346; Tue, 14 Sep 2021 17:11:39 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 14 Sep 2021 17:11:38 -0700 (PDT) In-Reply-To: <6db89043-7d5b-4856-b4e5-093219685b9bn@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=98.118.241.166; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 98.118.241.166 References: <6db89043-7d5b-4856-b4e5-093219685b9bn@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Custom Storage Pool questions From: Jere Injection-Date: Wed, 15 Sep 2021 00:11:41 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:62739 List-Id: On Tuesday, September 14, 2021 at 6:54:54 AM UTC-4, ehh wrote: > On Tuesday, September 14, 2021 at 2:48:16 AM UTC+2, Jere wrote: > > > > Yes, but if you look at that blog, they are allocating space for the /user/ data > > and for the Next/Prev for controlled types and First/Last for unconstrained > > arrays in addition to the size specified by allocate. > > > Yes, but if you look at that blog, they explain the default layout of fat pointers, > and the special value that need to be set on access types for the layout to > change. If you use such a GNAT-ism, your storage pool will also be bound > to GNAT... > > > ie: > "GNAT typically uses a "fat pointer" for this purpose: the access itself is in fact > a record of two pointers, one of which points to the bounds, the other points to > the data. This representation is not appropriate in the case of the header > storage pool, so we need to change the memory layout here." > > and: > "we need to ensure that the bounds for unconstrained arrays are stored next to > the element, not in a separate memory block, to improve performance. This is > done by setting the Size attribute on the type. When we set this size to that of > a standard pointer, GNAT automatically changes the layout," > What I am seeing in the blog is if I *do not* use the GNAT ism in my storage pool and assume that the Size parameter indicates the full size needed, then if someone uses my pool with a GNAT compiler it would erroneously access memory. You can clearly see the calculation in the blog is: Aligned_Size : constant Storage_Count := -- bytes Size + Header_Allocation + Extra_Offset; Where Size is specified by Allocate, Header_Allocation is the user supplied fields of the storage pool, and ***Extra_Offset*** is a separate size value that accounts for First/Last or Previous/Next Finalization_Master_Size : constant Storage_Count := 2 * Standard'Address_Size; -- for Previous and Next Extra_Offset : constant Storage_Count := (Element_Type'Descriptor_Size + Finalization_Master_Size) / Storage_Unit; -- convert from bits to bytes The blog quotes: """The size for the bounds is given by the attribute Descriptor_Size. For most types, the value of this attribute is 0. However, in the case of unconstrained array types, it is the size of two integers""" These values are specified separate from the Size parameter and added to it in the Allocate function shown in the blog there. If I were to write my own storage pool and I didn't do the Extra_Offset calculation and just assumed the compiler would call Allocate with the correct Size value for everything, the logic in that blog then would indicate that GNAT would assume I did the Extra_Offset calculation anyways and it could access those fields even if I didn't explicitly allocate them separately as GNAT does. In that case the fields would be part of some other object's memory or random memory. My original question is if the intended premise in Ada is that Storage pools aren't expected to be created to be portable due to just being low level because compilers can just assume you will know to allocate hidden fields in addition to what the Size parameter specifies. Does that help clarify what I'm confused on? Sorry, I am not great with wording.