Announcement

Collapse
No announcement yet.

Debugger didn't catch this error the same

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

  • Lance Edmonds
    replied
    Or use LBOUND & UBOUND...

    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Peter,

    Your array is still calling for a 7 element array. Perhaps
    if one wants to start at element one as shown in your example
    code, the code should be as follows:

    Code:
    %MAX_VALUE = 6
    
    DIM Value(1:%MAX_VALUE) AS STRING
    FOR i = 1 TO %MAX_VALUE
    Another way would be to add a lower bound equate, %MIN_VALUE.

    Code:
    %MIN_VALUE = 1
    %MAX_VALUE = 6
    
    DIM Value(%MIN_VALUE:%MAX_VALUE) AS STRING
    FOR i = %MIN_VALUE TO %MAX_VALUE
    Cheers,
    Cecil


    ------------------

    Leave a comment:


  • Peter Manders
    replied
    John,

    A good programming practice that would have prevented this error from ever occurring, is using constants.

    If you define a constant then you'll never have to go over your code to check values in your code anymore.
    Always try to use as many constants as possible:

    %MAX_VALUE = 6
    DIM Value(%MAX_VALUE) AS STRING
    FOR i = 1 TO %MAX_VALUE


    Peter.


    ------------------
    [email protected]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    John,

    I agree, the bounds checker should have caught this one, however
    the way the string array is dimensioned Value(5) is the same as
    Value(0:5) which is the same as Value(0 to 5). What you have is
    a six (6) element array with the first element, Value(0). The
    way your for/next loop is constructed, the first element is
    missed entirely. Maybe that's what you want!!!! Don't know?

    The for/next loop would have got them all as follows:

    Code:
    for x=0 to 5
       GetInput(Value(x))
    next
    Don't feel bad, it's a common mistake among "C" programmers to
    do the same thing, however the bounds checker will flag this
    one.

    Cheers,
    Cecil


    ------------------

    Leave a comment:


  • John Kovacich
    replied
    Originally posted by Lance Edmonds:
    #DEBUG ERROR ON is automatically applied by the debugger. One of the things that this metastatement does is enable array bounds errors to be intercepted without a GPF.

    Exceeding the bounds of an array is the programmers responsibility to avoid.

    The debugger was on, so I assumed #DEBUG ERROR ON was in effect, however, it
    apparently did not check array bounds on the CALL statement, but instead
    passed something to the DLL which caused IT to GPF.

    Catching errors may be the programmers responsibility, but the tools at hand
    are supposed to help them locate and identify these errors.

    Based on your statement, I would have expected array bounds checking to issue
    an error, which it did not, in fact, it acted as an IGNORE on the error
    which allowed the system to GPF later on.

    I've used a lot of compilers which provided an option to check errors, and
    provide useful debug messages to us. I don't think it is so hard to
    provide.




    ------------------
    Thanks,

    John Kovacich

    Leave a comment:


  • Lance Edmonds
    replied
    #DEBUG ERROR ON is automatically applied by the debugger. One of the things that this metastatement does is enable array bounds errors to be intercepted without a GPF.

    Exceeding the bounds of an array is the programmers responsibility to avoid.

    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Michael Mattias
    replied
    I think you need to interrogate ERRCLEAR or ERROR atr the time of the sin to catch it unless you have ON ERROR GOTO in effect.

    Also, if you are not trapping array bounds, you wouled expect to "sometimes" get a GPF, as your process may own the memory you overran into. In this case, no GPF, ,but you have corrupted your data.

    Same thing happens in mainframe COBOL when you overrun a table; you get your choice of four (bad) results:

    1. Corrupt your own data, resulting later in a S0C4 data exception ABEND (GPF)
    2. Corrupt your own data, not getting an ABEND, just getting crap output.
    3. Corrupt you own code segment, getting a SOC1 invalid opcode ABEND
    4. Try to access data outside your enclave (process), getting a SOC2 or S0C7 abend

    Overruning a table is a "fielder's choice" of errors.

    MCM

    Leave a comment:


  • John Kovacich
    replied
    But DEBUG ERROR ON is the DEFAULT when running from the Debugger!

    ------------------
    Thanks,

    John Kovacich

    Leave a comment:


  • Eric Pearson
    replied
    > Can (or do) we have an option for bounds checking?

    #DEBUG ERROR ON enables array bounds checking.

    -- Eric


    ------------------
    Perfect Sync: Perfect Sync Development Tools
    Email: mailto:[email protected][email protected]</A>

    [This message has been edited by Eric Pearson (edited February 20, 2001).]

    Leave a comment:


  • John Kovacich
    started a topic Debugger didn't catch this error the same

    Debugger didn't catch this error the same

    I don't know if its just a quirk or if it is addressable within the debugger,
    but I came across the following problem:

    DIM Value(5) AS STRING ' <==== I forgot to change this to 6
    DIM X AS LONG

    FOR X=1 TO 6 ' <==== I changed this from 5 to 6
    CALL GetInput(Value(X))
    NEXT X

    GetInput is a DLL. When I run from IDE/Debugger, it runs fine.
    When I run from outside debugger, it GPF's in the DLL.

    Can (or do) we have an option for bounds checking? It would have been
    helpful to catch this before going to the DLL, since the errors pointed
    to the wrong program. #DEBUG is not specified in either program, so
    I don't believe I have done anything to turn off bounds checking (if
    it ever existed). If bounds checking is not included, please consider
    this a vote to include it in the future.



    ------------------
    Thanks,

    John Kovacich
Working...
X