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,ASCII-7-bit X-Google-Thread: 103376,8893269a4640c798 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-28 14:23:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!snoopy.risq.qc.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: terminate applications References: <3F1D2FDC.1070402@noplace.com> <3F1DC75A.5050300@noplace.com> <87oezm9lar.fsf@inf.enst.fr> <3F1E7E1E.8090302@noplace.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 28 Jul 2003 17:08:47 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059426522 198.96.223.163 (Mon, 28 Jul 2003 17:08:42 EDT) NNTP-Posting-Date: Mon, 28 Jul 2003 17:08:42 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:40912 Date: 2003-07-28T17:08:47-04:00 List-Id: Dmitry A. Kazakov wrote: > On Fri, 25 Jul 2003 22:58:53 -0400, "Warren W. Gay VE3WWG" > wrote: >>"Dmitry A. Kazakov" wrote in message news:bluvhvsr5kagtd9ksjdlpasf2iamcgu67v@4ax.com... >> >>>On Thu, 24 Jul 2003 10:54:51 -0400, "Warren W. Gay VE3WWG" >>> wrote: >>> >>>Now, how this can support any need to incorporate that buggy API into >>>the standard? >> >>You are labelling it a "buggy API". I see this as a legitamate >>function. For example, if an some internal assertion fails, it may >>be highly desireable to have the whole application be "canned" >>immediately, without a shutdown (which might inflict further damage). >> >>The problem as I see it, is that there is a very strong tension between >>the embedded/rocket/life-threatening developers and those that write >>much more mundane applications. I feel this same tension is rearing >>its head here. If Ada is to gain wider exceptance, you need to take >>those blinkers off. ;-) > > What I am doing right now, is reviewing design of a C++ Windows > application which hangs upon exit! (:-)) The reason was unknown, so a > clever decision was made - just to wait a bit on application exit and > then if it is still active to kill it. A fine design? (:-)) Not at > all! Because it has 10+ DLLs and opens 20+ devices of various types. > So after a suicide, things are going strange, very strange. Do you > really want to legitimize such things in Ada? Fine, then statically link it ;-) I understand what you're saying (I am not a win32 fan myself). Under UNIX, this sort of thing is less of an issue. Perhaps the "issue" is unsolvable under win32. >>The embedded people don't want it because they don't want it used (to >>that I say fine, don't use it!) Ravenscar avoids a large portion >>of Ada features that it considers "unsafe". What harm can one more >>"feature" bring if it is correctly documented? > > Nobody reads documentation. (:-)) I see the smiley, but who's problem is that? ;-) > However, the place where a feature appears is already a sort of > documentation. When it appears in ARM body, then it is safe. In ARM > annex it could be a little less safe. In the package > Crappy.Windows.API it is, you'll get, what you asked for! (:-)) This naming convention at least places the correct blame 8-) >>To use an analogy you want to ban emergency brakes because they're >>weak, and almost useless. Yet every car in North America must have >>one. I think having the choice of an emergency brake makes sense. >>No one is suggesting that you should use it, or that it be recommended. >>It merely should exist to offer a choice for those practical >>situations where it might be useful and valid. > > No disagreement. But what I want, is to keep a sort of "sandbox" > design. Features of different safety levels should be put in different > boxes. From this point of view, an unconditional termination just does > not belong to the box of Ada standard. But it still may have a place > in OS-specific bindings. I won't disagree here, and have already suggested in other posts that as a compromise, that a pragma might be in order to allow/disallow such a "feature". -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg