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-25 20:16:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada References: <3F17DF3C.4080204@noplace.com> <3F196773.2060809@noplace.com> <3F19F86C.9050808@attbi.com> <3F1A772F.9060708@noplace.com> <3F1AD6FB.8080806@attbi.com> <3F1BD666.6040506@noplace.com> <3F1C4DA6.3070405@attbi.com> <3F1D29E8.60107@noplace.com> <3F1D2FDC.1070402@noplace.com> <3F1DC75A.5050300@noplace.com> <87oezm9lar.fsf@inf.enst.fr> <3F1E7E1E.8090302@noplace.com> <3F1FC849.8070202@noplace.com> Subject: Re: terminate applications X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Fri, 25 Jul 2003 23:16:19 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059189714 24.150.168.167 (Fri, 25 Jul 2003 23:21:54 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 23:21:54 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40822 Date: 2003-07-25T23:16:19-04:00 List-Id: "Randy Brukardt" wrote in message news:vi0gf8rnbu9b09@corp.supernews.com... > "Marin David Condic" wrote in message > news:3F1FC849.8070202@noplace.com... > > If most OS's provide a given feature, there ought to be a way for an Ada > > program to utilize that feature in a standard way. Worrying about the > > fact that some OS provided feature might not fit in with Ada's desired > > safety and security is what is going to guarantee that programmers are > > going to do end-runs around Ada to use the C/C++ library that *will* > > give them the feature - and eventually decide that its too much of a > > nuisance to be programming in both Ada and C and revert to C. > > I agree that common operations from the OS ought to be supported in a > standard way. But I disagree that that includes dangerous operations. But dangerous for whom? RAVENSCAR defines a number of Ada features that they consider "unsafe", yet these features are not soon to be removed from the "standard". You must look at the application first. The OP has an "application" for this feature, and I think it is presumptuous for us to say that it is too dangerous to be used. ... > Why should we go on propagating the mistakes of our forefathers? The > functionality is the important point, not the exact form or details. If you > don't believe that - if you believe that Ada can't be object-oriented > because it doesn't declare "class"es, for instance - then you SHOULD be > using C++. Ada has nothing to offer you then. Let me ask a hypothetical question: which car would you prefer? 1. Your year 2030 minivan says to you "I will not start because the hatch sensor indicates that it is not fully closed." "Please correct the problem or get it repaired and try again. Have a nice day!" or 2. Your year 2030 minivan says "I will not start because the hatch sensor indicates that it is not fully closed. If you have checked the hatch, and it appears OK, then enter code XYZZY and then I will proceed anyway." Which would you choose? Microsoft will offer the #1 firmware. For me, it better be #2, because I want to be in control! Not the so and so manufacturer! I think this API feature is about control. It has many times been conceded that this is not the correct thing to do. But there are _practical_ needs for this, if not for anything else, but for testing. > We should stick with "safe", well-defined operations in the standard Ada > library. After all, people will use those first. If they absolutely have to > use an unsafe operation, fine, but they'll have to do it by a direct > interface to the OS (making the OS dependence clear). > > (For what's its worth, the C Exit is a safe exit -- for C. It does lots of > finalization activities before it actually exits. Why should Ada be > different in that regard?) > > Randy. Ah, but exit() is only one C choice. The function _exit() is _also_ callable by the C programmer. Again, it is acknowledged that there are good reasons not to use this, but the C programmer DOES have the CHOICE to do so when it is required. Give the programmer a choice. Document it as dangerous or unsupported, but give the programmer the choice. Management can dictate it out of a project if it needs to. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg