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

[sampson@nosc.mil (Charles H. Sampson)]

In article <37er8t$oh0@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes:
>In article <1994Oct11.161048.1058@nosc.mil>, sampson@nosc.mil (me) 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.
>
     I was using "reliance on" in the same sense as the LRM use of "depends
on" in LRM 6.2(7).  If there's any essential difference between the two
phrases, it is escaping me.  I also don't see any difference between "reli-
ance on an operator" and "reliance on the result obtained when the operator
is applied".

     My point is that the C standard says that the integer division opera-
tor can give one of two possible results.  Any C programmer who relies on
getting a particular one of those results will find that he has the same
portability problem as the Ada programmer who (for whatever reason) creates
an erroneous program that relies on a parameter passing mechanism.  They
both must also face the small possibility that their programs will blow up
on the next release of their compilers.

>2. [What Ada calls "erroneous execution" the ANSI C standard calls
>   "undefined behavior".]

>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.

     Fair enough.  The behavior is defined, being limited to a finite set
(namely two) of possible outcomes.  It still looks to me like the careful C
programmer has the same problem with division as the Ada programmer does
with rounding.

>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.

     This discussion has caused me to reread, once again, the definition of
"erroneous execution" in LRM 1.6(7).  The gist is that there are certain
Ada rules that might not be caught by a compiler/runtime and if one of
these rules is violated the effect of execution is unpredictable.  The
interesting point to me is that the effect of executing a program that
relies on a particular choice of a compiler-dependent feature is also un-
predictable.  Does anyone know why programs that rely on an implementation
of a compiler-dependent feature were not also classified as erroneous?

                                   Charlie