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-12 23:21:01 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!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: 11 Oct 1994 20:06:53 GMT Organization: IBM T.J. Watson Research Center Distribution: world Message-ID: <37er8t$oh0@watnews1.watson.ibm.com> References: <36bsmq$5p@gnat.cs.nyu.edu> <36ej8t$1bsl@watnews1.watson.ibm.com> <1994Oct7.225248.6208@nosc.mil> <1994Oct11.161048.1058@nosc.mil> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: rios8.watson.ibm.com Date: 1994-10-11T20:06:53+00:00 List-Id: In article <1994Oct11.161048.1058@nosc.mil>, sampson@nosc.mil (Charles H. Sampson) writes: |> In article , |> Henry G. Baker wrote: ... |> >Sounds a bit like Ada's uncertainty about INOUT parameter passing |> >being 'by-reference' or 'by-copyin-copyout'. I don't think that Ada83 |> >even required that a particular subprogram do it the same way for |> >every call. |> |> All true, but at least the Ada definition acknowledges the indetermin- |> ism and says that any program that relies on a particular choice of imple- |> mentation is erroneous. I doubt that the C standard declares erroneous any |> program that relies on the division operator! Let's be fair: 1. The issue here is not "reliance on the division operator", but reliance on the direction in which a nonintegral quotient is rounded when the divisor or dividend is negative. 2. The ANSI C standard recognizes the equivalent of what the Ada standard calls "erroneous execution." The ANSI C standard calls it "undefined behavior". Like erroneous execution in the Ada standard, undefined behavior in the ANSI C standard arises in specific, precisely enumerated circumstances. (As you might guess, there are many more such circumstances in C than in Ada.) 3. The ANSI C standard does not say that dependence on the direction of rounding the quotient makes the behavior undefined, only that the direction of rounding is "implementation-defined". That gives the implementation much less freedom. It may round up or it may round down, but it may not overwrite a return address on the stack, for example. 4. In Ada 9X, the parameter-passing mechanism is mandated in many cases where Ada 83 leaves it up to the implementation. In the cases where it is still up to the implementation, the crime of "relying" on a particular mechanism has been more precisely defined and its severity has been reduced from "erroneous execution" (a captial offense) to "bounded error" (a noncapital felony). If a formal parameter has more than one "access path" (i.e., it is "aliased" in the pre-Ada-9X sense) and it is updated by one name, then examined by the other name, the possible outcomes are that the examination will yield the old value, that the examination will yield the new value, or (science fiction) that your very clever compiler will catch this error and raise the exception Program_Error. See RM9X-6.2(12) for the details. -- Norman H. Cohen ncohen@watson.ibm.com