Re: Division by zero

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

At least it's better than what happened to me when I ported a Pascal
program from a Norsk Data Pascal compiler to a Unix Pascal compiler.
Someone had used 1/0 intentionally to force the program to abort at
one place. The Unix Pascal compiler recognized that it could be
computed at compile time, and promtply dumped core....

>>>>> "L" == Lurker  <nowhere@nothing.com> writes:

    L> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
    L> news:79ahr0jozmqb$.10jzllrcjpmsv.dlg@40tude.net...

    >> > Well, yes. But can't it tell that division by zero is always wrong
    >> > regardless?
    >> 
    >> 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.

    L> OK, I see you point. But, pratically speaking, the chances are that
    L> that construct was an error. Perhaps a warning or some such would
    L> be enough. If whoever wrote that was sure that's what they meant - fine.
    L> But I was always under the impression that the Ada philosophy was
    L> to avoid accidental mistakes as much as possible. And division by
    L> zero sure should qualify as a suspect at least - not something that
    L> just happily gets compiled.

    >> >> 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. (:-))

    L> I'm afraid I don't follow your logic there. Do you really mean that
    L> a constant declared as = 0 cannot be detected at compile time?

    L> Yes, the effects of using it to divide something may or may not be ok.
    L> But that would equally apply to dividing a literal 1 by it, wouldn't it?

    L> (Again, I realise your point about static vs other expressions.
    L> But c'mon, unless someone specifically allows and handles
    L> cases like that, surely the safest bet would be to at least point
    L> out that there is something fishy going on and a "moral equivalent"
    L> of asking "are you sure"?
    >> 
    >> -- 
    >> Regards,
    >> Dmitry A. Kazakov
    >> http://www.dmitry-kazakov.de



-- 
   C++: The power, elegance and simplicity of a hand grenade.