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-26 13:24:58 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!tdsnet-transit!newspeer.tds.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: terminate applications
Date: 26 Jul 2003 15:24:55 -0500
Organization: Berbee Information Networks Corporation
Message-ID: <q5jLYypXp6Yg@eisner.encompasserve.org>
References: <mailman.18.1058521718.24167.comp.lang.ada@ada.eu.org>
 <FlQRa.89768$H17.28202@sccrnsc02> <3F17DF3C.4080204@noplace.com>
 <KcURa.91888$H17.28020@sccrnsc02> <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>
 <Pine.LNX.4.44.0307221421270.25598-100000@localhost.localdomain>
 <3F1D2FDC.1070402@noplace.com>
 <Pine.LNX.4.44.0307221518190.26977-10000Organization: LJK Software
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 1059250991 13580 192.135.80.34 (26 Jul 2003
 20:23:11 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Sat, 26 Jul 2003 20:23:11 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:40852
Date: 2003-07-26T15:24:55-05:00
List-Id: <comp.lang.ada>

In article <JrBUa.447$XK4.24411@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:etldVqgp8sE1@eisner.encompasserve.org...
>> In article <FTwUa.367$XK4.14917@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

>> > The other API entries (if useful), can be provided
>> > by a Halt.Aux package or some other extension perhaps.
>>
>> Presuming the VMS choices cover the universe of possibilities (doubtful),
>> what basis is there to think there is a uniform view of what is "the other"
>> method.
> 
> How many ways would you expect there to be in this "universe of program
> terminations"?  You seem to be implying that this could be huge (and thus
> a problem). I doubt that even more than your doubt, so there ;-)

It only takes two to cause a problem:

	One set of semantics supported by one group of operating systems.

	Another set of semantics supported by another group of operating
	systems.

So which of those should be chosen for operating systems on which either
set of semantics is supported by the operating system ?  Certainly that
should be part of the definition, rather than having two separate Ada
implementations do it differently on the same operating system.  Even
a loose "do what you can" definition is inadequate in that situation.