Re: Division by zero

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> writes:

> No, it is not, because it has a defined effect: Constraint_Error. Formally
> speaking division by zero is not a contract violation and thus cannot be
> "wrong". Consider the following:
>
> A : constant Integer := 0;
> B : Integer := 1;
> begin
> B := B / A;
> Put_Line ("Hello!");
> exception
> when others =>
> Put_Line ("Good bye!");
>
> The above is a valid program, which should print "Good bye!". At the same
> time the following is *wrong*:
>
> A : constant Integer := 0;
> B : constant Integer := 1;
> C : Integer;
> begin
> C := B / A;
>
> B/A is a static expression, which has to have a value at compile-time.
>
> The difference is not in what the compiler might know, but in what it must
> know.

True, but the RM could easily define that differently. For example, in
Ada 83, "1/0" was *not* considered a run-time error -- it must raise C_E
at run time. That was changed in Ada 95.

We could just as well add a rule that "B/0" is illegal.
But the general idea is that we let compilers generate
warnings in such cases, and don't worry too much about it
in the RM.

By the way, I believe your above example is wrong.
In particular, it can print "Hello!".
See RM-11.6. (This is why I don't like 11.6 -- reasonable programmers
*think* the above should print "Good bye!", but 11.6 says
it might not.)

> > What has actually happened (outside that toy example)
> > was that there was a constant declared in one place and used in
> > many others. Someone went ahead and changed it (for a good
> > reason) to zero. However, one of the uses of that constant was
> > to divide by it.
> >
> >> Constraint_Error will be raised at runtime.
> >
> > It was. My question was - should it have been caught
> > at compile time instead?
>
> I don't think it should. A class of errors which cannot be detected at
> compile time cannot be compile-time errors. Or, in other words, if you
> cannot rely on the compiler, you should not pretend you can. (:-))

Well, in Ada 83, the "class of errors" was "divide by zero".
In Ada 95, that was split into "divide by zero in a static expression"
and "divide by zero in a nonstatic expression" -- the former is a
compile time error, whereas the latter is a run-time error.
There's nothing illogical about splitting it further:
"divide by zero when the Right operand is static" could be defined
as a compile-time error. The problem is that if you try to define
all the compile-time-detectable cases very precisely, it gets quite
complicated. And however you define it, it *has* to be conservative.

- Bob
.

Relevant Pages

  • Re: C2124 is most disrespectful of IEEE floating point arithmetic
    ... Treatment of division by zero, forming a remainder using a zero ... For a compile-time expression, ... So depending on our handling of FP exceptions we should see one of two ... we have a compile-time error. ...
    (microsoft.public.vc.language)
  • Re: C2124 is most disrespectful of IEEE floating point arithmetic
    ... Division by zero is undefined, so the compiler can do whatever it ... For a compile-time expression, ... then the division by zero exception shall be signaled. ... a signed infinity; ...
    (microsoft.public.vc.language)
  • Re: Advice Needed...
    ... as, because they are, zero based. ... compile-time, based on the self-describing safearray data structure. ... To restate the actual point, requiring the programmer to do what's ...
    (microsoft.public.vb.general.discussion)
  • Re: Advice Needed...
    ... as, because they are, zero based. ... compile-time, based on the self-describing safearray data structure. ... To restate the actual point, requiring the programmer to do what's ...
    (microsoft.public.vb.general.discussion)
  • Re: Integers and standard
    ... Arithmetic overflow converting INTEGERto INTEGERat ... But note that it is quite common for run-time and compile-time error ... since we can't diagnose all cases of undefined variable usage at ... compile time, does that mean that for consistency, we should be sure to ...
    (comp.lang.fortran)
Loading