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!gandalf.srv.welterde.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: Ada.Containers and concurrent modification exception. Date: Fri, 21 Sep 2018 18:21:26 -0500 Organization: JSA Research & Innovation Message-ID: References: <168a229f-55de-4cb1-8405-8771e132d3ad@googlegroups.com> Injection-Date: Fri, 21 Sep 2018 23:21:27 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="9769"; 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:54398 Date: 2018-09-21T18:21:26-05:00 List-Id: wrote in message news:168a229f-55de-4cb1-8405-8771e132d3ad@googlegroups.com... >?????, 19 ???????? 2018 ?., 23:16:18 UTC+3 ???????????? Jeffrey R. Carter >???????: >> The ARM covers this case in ARM A.18.4(76-80) [I am unable to access the >> current >> ARM right now, so I'm quoting from ISO/IEC 8652:2007, which should be >> similar]: >> >> "A Cursor value is invalid if ... The node it designates has been deleted >> from >> the map. The result of "=" or Has_Element is unspecified if these >> functions are >> called with an invalid cursor parameter. Execution is erroneous if any >> other >> subprogram declared in Containers.Hashed_Maps or Containers.Ordered_Maps >> is >> called with an invalid cursor parameter. >> >> So J is invalid and Next (J) is erroneous. ARM 1.1.5(10) defines >> erroneous >> execution: "there is no language-specified bound on the possible effect >> of >> erroneous execution; the effect is in general not predictable." In other >> words, >> this call can do anything. > >That isn't right, even if it defined in reference manual. Depending on heap >usage, that >https://pastebin.com/H73KZ8Ti mess will work for years and in >one fine day may fail >for unknown reason. Of course it's right. The intent is that a cursor is directly implemented by a pair of access objects, and that is the behavior of a dangling pointer. (That is, all real programs in Ada (and C!!) have exactly this possibility - we've lived with it for 40+ years. Doing something different would have been too radical in 1980, and it's way to late to do that now - other than optionally). We wanted it to be possible for the Ada containers to be performance-competitiive with C++ containers, and expensive cursor checks would make that impossible. In particular, the only known way to implement perfect dangling cursor detection would be to make all cursors controlled and keep links from them back to their originating container. That would be much slower (5-10 times) on every cursor operation than the current definition -- and such an implementation would have been required had we not made the operations erroneous. (Note that the performance of the checks we did require are considered too expensive such that some of those will be eliminated from Ada 2020's definition.) That said, another goal was to allow (but not require) dangling cursor detection -- an implementation *can* detect dangling cursors if it wants. There are definitely schemes available that can detect 99% of such problems (noting that some corner cases can't be detected) without much extra overhead. It's also possible that an implementation could have a "checking" implementation of the containers to make such checks as well as a "fast" implementation that does not. Randy.