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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1888e8caa20a2f2d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Controlled types and exception safety Date: 02 Dec 2005 18:21:50 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <19lv2i0m39k6e$.ofebub7p4x97.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1133565710 6638 192.74.137.71 (2 Dec 2005 23:21:50 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 2 Dec 2005 23:21:50 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6726 Date: 2005-12-02T18:21:50-05:00 List-Id: "Randy Brukardt" writes: > Probably not specifically. Obviously it depends on the implementation. I > just looked at ours, and it does nothing at all to handle memory issues in > Adjust. That means that the object would fail the invariants after such an > assignment. (I didn't actually realize that; it would be better to null the > pointer in that case...) And presumably, it would eventually access through > a deallocated pointer. But that's all a correct (if unfriendly) > implementation of Ada, because the object is abnormal, and any access to it > is erroneous -- see 13.9.1. (Humm, this actually isn't as clear as it ought > to be; one could argue that Storage_Error isn't a "language-defined check" > (its not called that in 11.1(6)). I think 11.5(2) can reasonably be interpreted to mean that Storage_Error qualifies. Certainly, that is the intent. 11.5(22) also applies, although it incorrectly talks about specific reasons why S_E might be raised, whereas 11.1(6) says S_E can be raised by anything at all (not just "new" and procedures and tasks). >... But surely it is intended to be covered; Yes, surely. > it's hard to imagine a case that is more likely to corrupt things than > running out of memory. Well, I can imagine "abort", and that's just as bad (except that you can defer aborts, but you can't defer out-of-memory). - Bob