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,FREEMAIL_FROM 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-01-31 20:02:30 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn11feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller2.gnilink.net!nwrdny02.gnilink.net.POSTED!0e8a908a!not-for-mail From: Hyman Rosen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions 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> In-Reply-To: <101mf7ffjr9p9db@corp.supernews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 01 Feb 2004 04:02:29 GMT NNTP-Posting-Host: 162.84.157.220 X-Complaints-To: abuse@verizon.net X-Trace: nwrdny02.gnilink.net 1075608149 162.84.157.220 (Sat, 31 Jan 2004 23:02:29 EST) NNTP-Posting-Date: Sat, 31 Jan 2004 23:02:29 EST Xref: archiver1.google.com comp.lang.ada:5160 Date: 2004-02-01T04:02:29+00:00 List-Id: 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 realize you are using the term informally, but I think you're confusing a > lot of people by using it. Apparently, I was using it formally, and the confused people are confused :-)