Announcement

Collapse
No announcement yet.

Division-by-0 in debugger

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Division-by-0 in debugger

    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.

    Code:
    #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
    Gert Voland

  • #2
    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.

    Comment


    • #3
      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.
      kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

      Comment


      • #4
        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.
        Gert Voland

        Comment


        • #5
          > 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.
          kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

          Comment


          • #6
            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
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment

            Working...
            X