Board index » delphi » Strange RTE 200? (NOT THE CRT BUG)

Strange RTE 200? (NOT THE CRT BUG)

Hi guys!

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.

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?

(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!)

Arno Fehm

 

Re:Strange RTE 200? (NOT THE CRT BUG)


Just tried on my work one:

Cyrix 266
TP7 from Winblows 98... {$N+} = Invalid floating point operation,
{$N-} = Divide by zero.

On Wed, 17 Mar 1999 12:46:08 GMT, horst.krae...@snafu.de (Horst

Quote
Kraemer) wrote:
>On Mon, 15 Mar 1999 16:18:25 +0100, Arno Fehm <af...@bigfoot.de>
>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.

>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

From Paul
Quantum Business Systems
www.quantumsystems.com.au

PS- Remove NOSPAM from my email address to send me
a private message

Re:Strange RTE 200? (NOT THE CRT BUG)


Thanks for your information, but I have to add something!!

Quote
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!

Help appreciated!!
Arno Fehm

Re:Strange RTE 200? (NOT THE CRT BUG)


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

(...)

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

It surely depends on the value i has. As it is uninitialized,
it could be 0 in a context and /= 0 in another - my guess is that
0.0 / 0.0 returns 0.0 without crash. Try a write(i); before f := i / j !

--
Gautier

--------
Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html
Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm

Re:Strange RTE 200? (NOT THE CRT BUG)


On Thu, 18 Mar 1999 18:22:35 +0100, Arno Fehm <af...@bigfoot.de>
wrote:

Quote
> Thanks for your information, but I have to add something!!

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

OK. That's a horse of a different colour and it has nothing to do with
your CPU/FPU but with DPMI.

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

Regards
Horst

Re:Strange RTE 200? (NOT THE CRT BUG)


Quote
Horst Kraemer wrote:
> OK. That's a horse of a different colour and it has nothing to do with
> your CPU/FPU but with DPMI.

> 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

Oh yes, you are right!! When startet from a Win95 Dos-Box, it crashes as
expected!! Not, if executed either from the IDE directly or from a
DOS-box of the IDE itself!!

Thank you for this info!!

My final thoughts about that theme:
While developing, there should always be FP-emulation instead of 80x87
code. Even if it's slower. But it helps not being surprised of another
new kind of "RTE200-bug". I think, one should be enough! :-)

Arno Fehm

Re:Strange RTE 200? (NOT THE CRT BUG)


Quote
Gautier.DeMontmol...@maths.unine.ch wrote:
> It surely depends on the value i has. As it is uninitialized,
> it could be 0 in a context and /= 0 in another - my guess is that
> 0.0 / 0.0 returns 0.0 without crash. Try a write(i); before f := i / j Well, it completely did not depend on the value of i! It did not crash from the IDE, whether i was 0 or 1 !!

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?

Arno Fehm

Re:Strange RTE 200? (NOT THE CRT BUG)


On Fri, 19 Mar 1999 18:24:43 +0100, Arno Fehm <af...@bigfoot.de>
wrote:

Quote
> 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?

In TP up to 6.0 variables in static memory are uninitilized and their
values are random.

In TP/BP 7.0 _only_ in REAL mode static variables are initialized to
0-values (i.e. pointers to NIL, booleans to false, strings to '',
numbers to 0)

But this is an undocumented feature and there is not the slightest
excuse to rely on it.

In BP 7.0 Protected mode and Windows mode variables are _not_
initialized as usual.

Regards
Horst

Re:Strange RTE 200? (NOT THE CRT BUG)


In article <36F2885B.FB083...@bigfoot.de>, Arno Fehm  <af...@bigfoot.de> wrote:

Quote
>Gautier.DeMontmol...@maths.unine.ch wrote:
>> It surely depends on the value i has. As it is uninitialized,
>> it could be 0 in a context and /= 0 in another - my guess is that
>> 0.0 / 0.0 returns 0.0 without crash. Try a write(i); before f := i / j Well, it completely did not depend on the value of i! It did not crash from the IDE, whether i was 0 or 1 !!

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

TP 7.0 clears the data segment. I do not know of earlier versions.

Osmo

Re:Strange RTE 200? (NOT THE CRT BUG)


Quote
Arno Fehm (af...@bigfoot.de) wrote:

: 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?

Global variables are indeed automatically set to 0
in Borland Pascal 7, but you should better not count
on that since you run into problems as soon as you
wrap the code into a procedure.

Klaus
--
Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104 Freiburg
hartn...@uni-freiburg.de   http://www.brain.uni-freiburg.de/~klaus/

Other Threads