>> Today, I found something really strange.
>> What would you expect this code to do:

>> VAR i,j : longint;
>>     f   : real;
>> BEGIN
>>  j := 0;
>>  f := i / j;
>> END.

>it's hard to say. The variable i has a random value.
>If i=0 you will get a invalid floating point operation (RTE  207) (or
>a RTE 200 with {$N-}), otherwise a Division by 0 (RTE 200).

>> Shouldn't this give a RTE 200?
>> Well, if I compile with FP-emulation, it does crash as expected. But
>> when I use 80x87 code, it does not. This is on my P55C (200MMX).
>> At PCs of friends of mine, the very same thing DOES crash, they have got
>> newer CPUs like PII or AMD K6-2.

>> Is it possible, that this IRQ0 depends on the CPU?

>This error has nothing to do with IRQ0. IRQ0 is the timer hardware
>interrupt which is mapped to INT_8. What you mean is INT_0. But in
>this case it's floating point operation due to the / operator. This is
>handled either by software or by the Copro's hardware which will
>produce an INT_$75 if exceptions are enabled. TP will enable FPU
>exceptions.

>> (Why I'm interested: I had a program, that in special cases
>> unfortunately had a div by 0, but on my PC it worked, so I did not see
>> this problem, only my friends complained about it. I think it is
>> interesting to know that you can't even rely on errors today!)

>If it does not crash on your machine your hardware is buggy or broken
>- or you are cultivating a virus.

>Regards
>Horst

> > VAR i,j : longint;
> >     f   : real;
> > BEGIN
> >  j := 0;
> >  f := i / j;
> > END.
SNIP...
> If it does not crash on your machine your hardware is buggy or broken
> - or you are cultivating a virus.

> Horst Kraemer wrote:
> > > Today, I found something really strange.
> > > What would you expect this code to do:

> > > VAR i,j : longint;
> > >     f   : real;
> > > BEGIN
> > >  j := 0;
> > >  f := i / j;
> > > END.
> SNIP...
> > If it does not crash on your machine your hardware is buggy or broken
> > - or you are cultivating a virus.
> You do not believe me?
> But I am 100% sure, it DOES NOT CRASH!
> New information: It does crash in REAL MODE, not in PROTECTED MODE!
> The result for f (in case of "no crash") is 0.000E+00, even when f is
> set to something else before the operation.
> Isn't there any other possibility why this thing does not crash with
> this configuration:
>  Intel Pentium MMX 200
>  80x87 code (no emulation)
>  Protected Mode
> Please do all test this code!!! This must be CPU-spezific!

> Please test it at the command line and not from the IDE BP.EXE.

> I suppose the program doesn't crash in the IDE but it does as it
> should if executed from the command line. I can reproduce this
> behaviour. This seems to be a problem limited to the IDE BP.EXE and
> the de{*word*81} TDX.EXE

>But another question about this:
>Are uninitialized vars (NOT POINTERS!!) not always 0??
>Ok, it is not fine programming style, but if you can count on it, why
>not to use this pre-set value?

>Question: Are these vars set to 0 automatically?