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!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Bug in GNAT? - Max_size_in_storage_elements insufficient Date: Wed, 19 Oct 2016 19:59:08 -0500 Organization: JSA Research & Innovation Message-ID: References: <647636100.498533813.258228.laguest-archeia.com@nntp.aioe.org> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1476925115 17217 24.196.82.226 (20 Oct 2016 00:58:35 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 20 Oct 2016 00:58:35 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:32142 Date: 2016-10-19T19:59:08-05:00 List-Id: "Luke A. Guest" wrote in message news:647636100.498533813.258228.laguest-archeia.com@nntp.aioe.org... > Dmitry A. Kazakov wrote: > >>> Well, then it's at least a bug in [Barnes] because there's an example >>> like the above ones just with a simpler type. But I still think the idea >>> here is/was to provide enough space for N items of some type. >> >> I am not sure if that were technically possible. Considering an >> implementation of, for example, a marked-margins pool, the penalty to >> have a guarantee would be extremely high. > > Surely that's what a static language can supply, the actual amount of > space > required? Depends on the implementation of the storage pool, of course. The amount of memory used by objects can be figured out at compile-time (assuming that the subtype is definite and there aren't any discriminant-dependent components - it's possible to declare such objects non-contiguously), but the pool will have some overhead. Besides, that's irrelevant. S'Max_Storage_Size_in_Elements is not a static attribute and thus doesn't have to be calculatable at compile-time. The OP's example is legal because the value of Storage_Size doesn't have to be static, either. Of course, that means that whatever the OP is trying to do probably isn't going to happen here. Turning to the OP's question: I would never expect to be able say anything useful about the size of a task object - it's going to have to be allocated in pieces all over the memory map (there's limits on where the stack can be allocated, for instance). No attribute (Size, Object_Size, Max_Storage_Size_in_Elements) can have anything useful to say about non-contiguous objects. Note: I've always interpreted Max_Storage_Size_in_Elements to apply to a single call to Allocate; there might be multiple calls to Allocate to allocate a single object (Janus/Ada works this way; there is a separate call to Allocate for each contiguous part of an object). Indeed, I wrote the definition of the attribute with this model in mind. Whether any other Ada lawyers would agree with me is unclear. :-) Randy.