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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: abo@minkirri.apana.org.au (Donovan Baarda) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/11 Message-ID: #1/1 X-Deja-AN: 256233869 References: <33C56F97.1223@gsfc.nasa.gov> X-Server-Date: 11 Jul 1997 13:29:45 GMT Organization: Minkirri Internet Access Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-11T13:29:45+00:00 List-Id: On Thu, 10 Jul 1997 19:26:17 -0400, Mike Stark wrote: >Don Harrison wrote: >> >> Tucker Taft wrote: >> > >> :and little or no use of dynamic storage allocation after >> :system startup. >> : >> :Eiffel's dependence on dynamic storage allocation and garbage >> :collection basically rules it out for most (serious) safety-critical >> :applications, despite all its admittedly nice invariants and assertions. >> [snip heaps of stuff about the evils of dynamic memory allocation in safety critical applications, and how to get around it in various languages such as turning off the GC!!] I can't help but think that the reason dynamic memory allocation got such a bad rap in the first place was there was no GC in old languages. Turning it off seems to me like a step backwards. Absolute control of memory allocation has been seen as necisary in safety critical systems because you need to be sure that you will never run out of memory and never write things over each other. Dynamic memory allocation made proving this much harder, so the safety people just banned it, and used the measurable decrease in failures as proof. Kill dynamic memory in C and it becomes a hell of a lot more reliable. However, GC has changed the whole landscape a bit. I wonder if anyone has tried to formally prove that a GC will ensure you never die from running out of memory in a program with strictly controlled objects in a controlled environment? Programs are so complex today that doing safety analysis right from the bottom (like where variables are allocated in memory) up for every program is getting out of the question. At some point there is going to have to be a heriachical aproach to safety, where low level tools (such as GC) are proven safe first. Future programs can use these tools, and can have the safety analysis done at a higher level without worrying about proving the low level tools all over again. I'm sure GC would improve safety, but I wouldn't want to try and convince the safety people. Safety people are by nature, and probably necesity, conservative people and will take a hell of a lot of convincing before they will let you do anything the new way, even if it is safer. I also wouldn't want to try and provide the proof :-) ABO