Re: Processing a List from a command

On 16 January 2017 at 10:04, Jeff Young <jyoung0950@xxxxxxxxx> wrote:

I have changed my code to use pointers to get the offsets and then each
list entry as follows:
D InBoxData Ds 322
D Entries 2B 0

D Offset S 2B 0 Based(Offset_Ptr)
D Box_Data S 30A Based(Boxing_Ptr)

C If Entries > *Zero
C* Set pointer for Offset to start of input data
C Eval Offset_Ptr = %Addr(InBoxData)
C* Set pointer for list entry
C Eval Boxing_Ptr = %Addr(InBoxData)

Boxing_Ptr starts at B2

C For Ix = 1 to Entries
C* Set pointer to next offset
C Eval Offset_Ptr += 2
C* Set pointer to next list element
C Eval Boxing_Ptr += (Offset +2)

On the first pass, Boxing_Ptr becomes B2 + 48, or FA.
On the second pass, it becomes FA + 28, or 0122. This is clearly
incorrect; the second list starts at B2 + 28.
On the third pass, it becomes 0122 + 08, or 012A which pushes the
Boxing structure outside of the memory the code allocated for it.
This code will do naughty things at some point!

C Eval Boxing = %Trim(Boxing) + Box_Data
C EndFor
C EndIf

I'm not sure what it is that the code needs to do with the returned
data, but my funny bone is tingling at the idea of taking a fixed
length structure and stripping leading + trailing blanks to aggregate
it into a single string.

One other thing. Don't use 2B 0. I know that this particular example
won't overflow 99, but it's a bad habit to get in to. The actual
returned data can be up to x'ff' - 255, and a 2B 0 can't hold that.
There is exactly one place that the B data type should be used, and
I've only ever seen it once in 35+ years. That place is when the
decimal position is not 0, so something like 9B 2. Aside from that
one use, use an appropriate integer data type, whether it be signed or
unsigned. In my example code I used 10i 0 and that's probably wrong -
I should have used 10u 0 because these counts and offsets aren't ever
going to have negative values in them.

--buck