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,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-02 17:56:05 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!fr.ip.ndsoftware.net!proxad.net!freenix!sn-xit-02!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Mon, 2 Feb 2004 19:54:28 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <101tvs0eh3eib26@corp.supernews.com> References: <1075225041.167448@master.nyc.kbcfp.com> <1075303237.975898@master.nyc.kbcfp.com> <9khh10pti0dn8gcp7f18ghptaifluj0fud@4ax.com> <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> <1075482385.142744@master.nyc.kbcfp.com> <101mf7ffjr9p9db@corp.supernews.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:5192 Date: 2004-02-02T19:54:28-06:00 List-Id: "Hyman Rosen" wrote in message news:pT_Sb.6670$bn1.3505@nwrdny02.gnilink.net... > Randy Brukardt wrote: > > Sorry, Hyman, but Ada has a very specific meaning for "unspecified result", > > and that's what people here (usually) mean. "Unspecified" means not only is > > *any* result allowed, but also that the implementer doesn't even need to > > tell you what the result will be. > > That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM: > Certain aspects of the semantics are defined to be either > implementation defined or unspecified. In such cases, the > set of possible effects is specified, and the implementation > may choose any effect in the set. Implementations shall document > their behavior in implementation-defined situations, but > documentation is not required for unspecified situations. > > So I would have to say you're wrong. Unspecifed behavior allows the > implementation to choose from a limited set of possible effects, not > from an unlimited one, and the implementation doesn't have to tell > you what it chooses. I think you're misinterpreting the meaning of this paragraph. Only bounded errors always give a set of possible results. There is an implied requirement for sensible choices, but certainly the RM rarely if ever gives a set of results for either I-D or unspecifed. Try 13.9(11), for instance (Unchecked_Conversion). It says that the result is I-D, but never says anything about the possible results (other than that it may be abnormal!). I know of compilers that reject such conversions; others do various masking operations; and still others raise exceptions. That's pretty close to the entire set of possible results! I note that the AARM notes say "Note that the ``set of possible effects'' can be ``all imaginable effects''; which seems to be the default case. So I think that the only purpose of that phrase is to allow the RM to give a set of possible results -- something it rarely if ever does. Randy.