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,c1b1b81e16e83802 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-03 00:24:49 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_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F03DA3D.5050102@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: Help-memory allocation References: <87y8zjvckv.fsf@deneb.enyo.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1057217088 24.62.164.137 (Thu, 03 Jul 2003 07:24:48 GMT) NNTP-Posting-Date: Thu, 03 Jul 2003 07:24:48 GMT Organization: Comcast Online Date: Thu, 03 Jul 2003 07:24:48 GMT Xref: archiver1.google.com comp.lang.ada:40005 Date: 2003-07-03T07:24:48+00:00 List-Id: Vinzent Hoefler wrote: > Mmh, so in case someone relies on the occurence of the exception in > the very moment of the allocation, would it be wise to also give an > initial value to make sure we actually "use" the allocated memory? Dave Emery likes to describe Storage_Error as a parachute that opens on impact. The problem is not in the definition of allocators, but that there may be temporary storage used when evaluating an expression. So the allocator can use up almost but not quite all of the storage, and you will then get a Storage_Error exception somewhere downstream. Unless you carefully track how much storage is used by your program and where, you have to allow for the possibility of Storage_Error anywhere. Of course, on a decent virtual memory system, most programs will use so little memory compared to the (virtual) Gigabytes allocated to that process that Storage_Error will only occur if you run out of disk space. There are cases in Ada where handling Storage_Error is useful. For example if you are potentially creating a large object on the stack, not the heap. But in other cases all Storage_Error tells you is that you crashed. Actually, there is an even worse case. You can have a handler for Storage_Error in just the right place, and catch Storage_Error when it occurs--but then the exception handler uses some memory and boom! Storage_Error is raised again, outside the error handler. Nice OSes save a block at the end of the stack which is released when a stack allocation error occurs so that the first Storage_Error can be handled nicely. But such a block can only be used reliably once per process. -- 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.