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-Language: ENGLISH,CP1252 X-Google-Thread: 103376,386228a37afe967f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-20 06:28:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F1A98F4.3090304@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Computer Language Shootout References: <1ec946d1.0307150715.4ba69f85@posting.google.com> <3F149243.80304@attbi.com> <3F15930C.2070907@attbi.com> <87k7aeqfcf.fsf@inf.enst.fr> <3F19E1BB.5000908@attbi.com> <87n0f9poyc.fsf@inf.enst.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 66.31.71.243 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1058707716 66.31.71.243 (Sun, 20 Jul 2003 13:28:36 GMT) NNTP-Posting-Date: Sun, 20 Jul 2003 13:28:36 GMT Organization: Comcast Online Date: Sun, 20 Jul 2003 13:28:36 GMT Xref: archiver1.google.com comp.lang.ada:40523 Date: 2003-07-20T13:28:36+00:00 List-Id: Samuel Tardieu wrote: > I don't think so. Also, you can bet that beginners will use such a > convenient function without understanding the implications for the > stack, and will soon be hit by a stack exhaustion. What implications for the stack? If the next line is too large to fit on the stack, there is a problem. If it isn't, then there won't be any stack space lost and unreclaimed. I personally use exactly this idiom, in fact if you look you can find a recent case where I posted code that used it to read an entire file into one String. (The stack space used is roughly bounded by 2*file size, and the documentation in the code mentions that this program is intended for small files.) I also think you misunderstand my meaning about adding the function to Text_IO. The only thing added by the An implementation would NOT use this implementation of the function. If I were writing it, I would use a (OS specific) call to find out how many characters I would read, if available, and create exactly that much space on the stack. If I couldn't determine the size, I would read into a relatively large scratchpad in the heap, and deal with overruns carefully. In any case, I would check the remaining stack space and raise Storage_Error rather than overflow it. (But that would be done, if necessary, as part of the normal function return code, since the value might not go to the stack.) Dave Emery calls Storage_Error a parachute that opens on impact because it can't guarantee that you have enough stack space to run the handler. However, if this function is in the RM, then it is much more likely that Storage_Error will be raised in a place where reasonable handlers have enough (stack) room to operate. Remember that an implementation has lots of extra abilities like this, since they can generate "implementation dependent" code all over the place without concern. > The RM does acknowledge that stacks exist through task-specific > storage controlled by pragma Storage_Size applied to a task. But the RM does NOT require that a function return a String (or any other array value) on the stack. This is deliberate. An implementation can return such values on the heap, and ensure that the storage is reclaimed by the caller. In the "normal" idiom for a using a Get_Line function: begin -- may a subprogram begin or a block while not End_of_File loop declare Line: String := Get_Line; begin --process line end; end loop; exception -- Errors raised by Get_Line take you here... end; even if the storage reclamation is deferred until the end of the declare block, no harm is done. Where the exceptions are handled may come as a surprise to beginners, but it shouldn't. But notice that an implementation can choose--for this particular code structure--to optimize things by merging the blocks into the stack frame of the surrounding subprogram. If it does, it can either grow and shrink the stack frame with each iteration of the loop, or put the storage for Line on the heap, and reclaim it each time around the loop. All of this comes under what should be called the "as if" clause in the RM 1.1.3(15)--the user visible effects are all the same. (For reading a huge line, in one case the potential Storage_Error will come from stack overflow, and in the other from heap overflow, but that is well within the "as if" semantics rule.) -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller.