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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,18069d15345a10c8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-13 18:42:15 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!EU.net!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen From: ncohen@watson.ibm.com (Norman H. Cohen) Newsgroups: comp.lang.ada Subject: Re: Modulus and Remainder operations (Was Re: Help with a bit of C code) Date: 13 Oct 1994 21:34:25 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <37k951$153e@watnews1.watson.ibm.com> References: <1994Oct11.161048.1058@nosc.mil> <37er8t$oh0@watnews1.watson.ibm.com> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Date: 1994-10-13T21:34:25+00:00 List-Id: In article , hbaker@netcom.com (Henry G. Baker) says of the bounded error that results from aliasing subprogram variables: |> But this policy is still a crock, especially for |> Ada 'limited' types, because the definer of the type has lost control |> of the type. The 'textbook' definitions of prototypical limited types |> such as 'bank accounts' are no longer safe in the presence of such |> equivocation. |> |> See "How to Steal from a Limited Private Account--Why Mode INOUT |> Parameters for Limited Types MUST be Passed by Reference". Ada |> Letters XIII, 3 (May/June 1993), 91-95. This paper is also in my ftp |> directory. Henry, you seem to be envisioning some sort of adversarial relationship between the writer of a limited private type and the client who uses the type. It makes more sense to think of the limited private type as an appliance that is used by the client. If you use it properly, it is guaranteed to work; if you abuse it, you void the warranty. The client who uses the limited private type in a way that violates the rules of Ada is the one responsible for the fact that the properties of the limited-private type are violated, and it is his program that breaks. If your point is simply that a "bounded error" can have consequences more wide-ranging than one might suspect from the innocuous-looking lists of possible outcomes (use the old parameter value, use the new parameter value, or raise Program_Error), then your point is well taken. It's still a step forward from Ada 83, where the same rule violation is considered erroneous, which means in effect that the underlying abstract machine is broken and NOTHING is guaranteed. -- Norman H. Cohen ncohen@watson.ibm.com