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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,61e9062c1f23b9d5 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!storethat.news.telefonica.de!telefonica.de!newsfeed.stueberl.de!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: contracted exceptions Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1181165630.012508.55290@i38g2000prf.googlegroups.com> <19fxsxv1god43$.1pqq8vgfu2itn$.dlg@40tude.net> <4669BBBB.8040806@obry.net> <1svme16jhnvn9$.j4urjfrb9d2i$.dlg@40tude.net> Date: Sun, 10 Jun 2007 11:21:13 +0200 Message-ID: <1bdis2cetha2n$.1dqczzn46b49o$.dlg@40tude.net> NNTP-Posting-Date: 10 Jun 2007 11:20:52 CEST NNTP-Posting-Host: 595f3825.newsspool2.arcor-online.net X-Trace: DXC=V78^\DPYfP:RadXUBHgFh3A9EHlD;3Yc24Fo<]lROoR18kF[ On Sat, 09 Jun 2007 16:43:08 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> Maybe a sort of rendezvous on the predefined entry point with the parent >> task? > > Maybe. Will you let me define entries of the environment task? ;-) No, but you can always design it as: env task appl. Ada root task all other children >>... When the parent task accepts it, the exception is propagated out of >> the point of rendezvous in the parent, while the offending task finally >> rests in peace. When the parent task does not have this entry, then it >> (with all its children) is terminated. The process continues until >> rendezvous accepted or else death of the main task. > > Hmm. I guess the important thing is that the RM should define this > situation (exception propagation reaches the end of the task body) as an > error. That would encourage implementations to print error messages, > and debuggers to take control in such situations. Printing messages is not enough. One would like to be able to handle this within the program. BTW, if task were a controlled type, you know... (:-)) >>> My solution: allow the programmer to declare that certain regions of >>> code cannot run out of memory. The compiler must reserve enough memory >>> (and if can't, then raise S_E before entering that region). Of course, >>> what you can do in such a region is implementation dependent. >> >> Contracted exceptions? Let the user declare a subprogram with the contract >> of no Storage_Error. Then the compiler checks that code and if it cannot >> generate it in a way that would reserve all necessary memory before >> entering the body, it would refuse to compile it. > > The implementation can always calculate (at link time) a worst-case > amount of stack space that might be needed. The worst case might be the > size of the address space in some cases (recursion, X:String:=..., etc). > But the implementation cannot know statically whether that space will > be available at run time, unless the entire program has that property and "no Storage_Error" contract could be an easy way to have this property on subprogram basis. It does not say that Storage_Error will not be propagated at a call point. It says that it will not if the caller has no Storage_Error in its contract as well. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de