Ever had this problem? If you haven't yet, you may in the future, so read carefully . . .
A procedure falls over with a space violation error, but no pointers to objects are being altered where the error occurs. The error is on an EVAL statement which looks like this:
Eval g_ListEntryPtr =
g_ListSpacePtr +
g_ListOffset -
g_EntrySize +
(g_EntrySize * g_EntryNum)
g_ListSpacePtr is a space pointer addressing the start of a User Space, and the other terms are scalar (i.e. 'just numbers'). The receiving variable g_ListEntryPtr is another pointer variable, but it is not addressing anything. All variables are global (hence the 'g_' prefix) and may be referenced in other procedures in the same module (p_UsrSpc).
So, what is happening here for an error to occur?
In the EVAL statement, the value obtained after each term is evaluated will be stored in a compiler-supplied intermediate (working) variable.
The evaluation proceeds thus:
Step 1: Evaluate terms in parentheses
(g_EntrySize * g_EntryNum) = 1070 * 1 = 1070
(This result is stored in an internal compiler variable of scalar type.)
Step 2: Evaluate in order left to right
a) g_ListSpacePtr + g_ListOffset = [address] + 260 = [new address]
(This result is stored in an internal compiler variable of POINTER type.)
b) - g_EntrySize = [new address] – 1070 = [newer address]
(This result is stored in the SAME internal pointer variable as before.)
At this point the program fails, because when the compiler created the internal pointer variable, it created it so that it pointed to the object addressed by pointer g_ListSpacePtr. Since the internal variable's value is LESS THAN the value that is the actual base address of the object, the system determines that an address error (space violation) has taken place.
How do we get around this?
By re-arranging the arithmetic, we can prevent the address from being made effectively 'negative' with respect to the start of the addressed object:
Eval g_ListEntryPtr =
g_ListSpacePtr +
g_ListOffset +
(g_EntrySize * g_EntryNum) -
g_EntrySize
As you see, the subtraction is now at the end of the set of terms and will be evaluated last. Another way would be to put ALL the non-pointer terms into parentheses so that the intermediate results would not be applied to the pointer variable until all their evaluations were complete:
Eval g_ListEntryPtr =
g_ListSpacePtr +
( g_ListOffset + (g_EntrySize * g_EntryNum) - g_EntrySize )
Of course, a better way would be for IBM to STOP allowing compiler-created internal variables to become involved in object addressing!
---------------------------
About the author: John Blenkinsop is a senior programmer at NYK Logistics & Megacarrier in London, and he is a site expert on Search400.com.
