Debugger didn't catch this error the same

[Lance Edmonds]

Or use LBOUND & UBOUND...

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

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:

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

%MIN_VALUE = 1
%MAX_VALUE = 6

DIM Value(%MIN_VALUE:%MAX_VALUE) AS STRING
FOR i = %MIN_VALUE TO %MAX_VALUE

Cheers,
Cecil


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

[Peter Manders]

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]

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:

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


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

[John Kovacich]

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

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

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

[Michael Mattias]

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

[John Kovacich]

But DEBUG ERROR ON is the DEFAULT when running from the Debugger!

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

John Kovacich

[Eric Pearson]

> 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).]

[John Kovacich]

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