Re: Modulus and Remainder operations (Was Re: Help with a bit of C code)

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <1994Oct11.161048.1058@nosc.mil>, sampson@nosc.mil
(Charles H. Sampson) writes: 

|> In article <hbakerCxFK2p.4wp@netcom.com>,
|> Henry G. Baker <hbaker@netcom.com> 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