Division-by-0 in debugger

[Gert Voland]

Hi,

does anyone know why a division by 0 of a signed integer ends up with a
different result when executed directly ( => 0 ) or when run in the
IDE-debugger ( => -2147483648).

Rgds,
Gert.

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
    LOCAL i AS WORD     'unsigned integer
    LOCAL j AS LONG     'signed integer
    LOCAL k AS SINGLE   'floating-point

    i = 10
    j = 11
    k = 12
    PRINT "i, j, k before: "; i, j, k
    
    'division by 0 does not get trapped at runtime!
    i = i/0
    j = j/0
    k = k/0
    PRINT "i, j, k after : "; i, j, k
    WAITKEY$
    
END FUNCTION

[John Gleason]

I don't know why the different types produce different results or why the IDE is different than the .exe, but the docs have this to say about it:

In order to generate tight, fast code, we have eliminated quite a bit of error checking that was done in earlier compilers (such as Division-by-Zero, Numeric Overflow, and most other numeric checking errors). While this results in code that is considerably smaller and faster than any other Windows compiler product, it does put more of an onus on the programmer to write code that is bug-free, or code that does its own error checking and validation of its data.

[Kev Peel]

The simple explanation is that the output of an illegal operation is not guaranteed, just like when you write to invalid memory area, you don't always get a GPF. The solution is to always check for 0 before dividing.

[Gert Voland]

John, Kev,

Yes of course, it is an unwanted operation and the result is not defined
in any way ...
And since it doesn't get trapped at runtime one would expect the debugger
to return the same result as the direct execution - to support debugging.
Or is that too much to hope for?

By the way, the new PBCC V5.0 metastatements DEBUG CODE ON/OFF do
not make any difference in this case.

Gert.

[Kev Peel]

> Or is that too much to hope for?

Yes, since the result is undefined, it could be any value at any time. I believe the ASM code output for the debugger is slightly different, so this may explain it, but the result is still the same - an invalid value.

[Michael Mattias]

Send in an NFS for '#DEBUG OVERFLOW ON' and get yourself a checkmark. I first asked for this in '01 or '02.

FWIW: this could/would carry a significant run-time performance penalty, so that's why I suggested it be an option. (#DEBUG OVERFLOW OFF being the current state of affairs).


MCM