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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack) Date: Thu, 30 Aug 2018 18:40:02 -0500 Organization: JSA Research & Innovation Message-ID: References: <69e04c61-8ea3-40e2-bb9d-e5a128247df3@googlegroups.com> Injection-Date: Thu, 30 Aug 2018 23:40:03 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="18635"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: reader02.eternal-september.org comp.lang.ada:54301 Date: 2018-08-30T18:40:02-05:00 List-Id: "Jere" wrote in message news:69e04c61-8ea3-40e2-bb9d-e5a128247df3@googlegroups.com... > On Tuesday, August 28, 2018 at 8:24:23 PM UTC-4, Randy Brukardt wrote: ... > I have a question about this as it has always bothered me. The > section that specifies that is under Implementation Advice, which > doesn't sound binding. Correct. > That sounds more like it is a suggestion > to the vendor rather than a requirement. Is Implementation > Advice such that a conforming Ada compiler must follow it > (so not really advice at that point)? No, but a conforming compiler needs to document any advice that they don't follow. The only problem with that is that I'm not aware of any compilers that actually do that (at least in an easy-to-use-form). Ada 83 compilers used to be required to have an annex F for validation purposes (note: it's Annex M in Ada 95 and later), but that requirement was dropped decades ago. I once tried to do this documentation, but that that time there was no listing of Implementation Advice and as such I ended up abandoning it almost immediately. (We've since corrected that oversight in the Standard.) One of the major problems is that for a lot of these things, it would require a lot of compiler spelunking to figure it out what actually happens. (You would need to keep track of them as things are implemented to even have a chance.) It's easier to answer specific questions than to track down several hundred obscure issues that no one may ever care about. > I've intentionally avoided > bounded containers in situations where I want portability for > some of my embedded targets that don't use heap because it > doesn't sound guaranteed that it will not use heap, even > if my current compiler implements it that way now. In theory, you compiler vendor is supposed to tell you if they do any such things. In practice, it would be bizarre to support Ravenscar and then not let any containers work with it. Only a crazy vendor would do that on purpose, and surely any sane ones would take a priority change request on such things. (Janus/Ada doesn't support Ravenscar, and it's nearly impossible to write a generic that doesn't use the heap, but no one is going to expect to use Janus/Ada in such an environment anyway. But even so, we don't plan to use any explicit heap in the bounded containers -- whatever implicit stuff the compiler does is not really under the control of a programmer.) In practice, I would be surprised if a vendor suddenly started using heap intentionally in one of these containers. Most likely, if they are targetting no-heap applications, they're well aware that bounded containers are supposed to be used in such scenarios, and would intend to keep that the case. Note that there never is a guarantee of anything with a new compiler version: a new bug could cause your code to not compile or malfunction; new enforcement of a previously missed rule could cause your code to be rejected, and so on. Some care is always required. Randy.