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!mx02.eternal-september.org!feeder.eternal-september.org!au2pb.net!feeder.erje.net!2.us.feeder.erje.net!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada.Strings.Fixed.Count raises Storage_Error Date: Wed, 29 Jun 2016 16:30:45 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <57346ac8$0$4570$426a74cc@news.free.fr> NNTP-Posting-Host: shell02.theworld.com Mime-Version: 1.0 Content-Type: text/plain X-Trace: pcls7.std.com 1467232200 14164 192.74.137.72 (29 Jun 2016 20:30:00 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 29 Jun 2016 20:30:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:8KYJX0Urdb6pBMmO/bbyhGHA+Sw= Xref: news.eternal-september.org comp.lang.ada:30975 Date: 2016-06-29T16:30:45-04:00 List-Id: Niklas Holsti writes: > Thanks for this information, Jean-Paul. Jean-Pierre. > ...According to your post in > http://computer-programming-forum.com/44-ada/cdf3e22c34c4de36.htm, this > "pathology" was present in Ada 83, but was cured in Ada 95: "It was > related to a function returning a local task object, which is no more > allowed." Yes, but that was a bad design. Ada 2005 fixed the problem in the right way. It's unfortunate that we had to introduce incompatibilities along the way, instead of figuring out the right way in the first place. > This suggests to me that the definition of Ada 83 was either ambiguous > in this case, ... No, it was not ambiguous. It might have surprised the language designers, but the Ada 83 RM was clear: you could return a task outside its master, and that task must be terminated by that time. >...or required too much effort from the implementation for > this feature compared to the benefits of the feature, ... The benefits were exactly zero, so ANY implementation effort was "too much". But the real problem was that without heroic efforts, implementations would be forced to leak memory. I know of one Ada 83 implementation that counted the tasks as they were terminated. For the first 10, it did not free memory. After that, it did. It just so happens that the ACVC test for this malfeature created 10 tasks, and made sure they still existed (in the terminated state) after the function return. >...and consequently > the language was changed to eliminate the feature. Yes, but the issue was bigger than just tasks. Function return is always by copy in Ada 83, and limited types (including those containing tasks) should not be copied, but the RM required them to be copied anyway. Limited types didn't really work right until Ada 2005. - Bob