Go Back
3 Votes

Basic Compile Time Checking of Boundry Conditions Should Be Performed


Consider the following toy Traditional Synergy Application:
  

main
	stack record
		myAlpha, a10
	endrecord
proc
	myAlpha(8,12) = 'AAAA'
endmain

WITHOUT Bounds (qcheck) turned on, this program will compile just fine normally.

If you turn on qcheck it will error as expected.

However I do not understand why this very basic bounds checking is not just performed out of the box, I cannot think of a valid reason for over-indexing this variable in this manner. Can someone shed some light on this?

This appears to cause a SUBSCR (https://www.synergex.com/docs/index.htm#errors/run/trap/runSUBSCR.htm) at runtime, so I question why we would not attempt to catch it at compile time (without turning on any flags)?

3 Comments | Posted by Ace Olszowka to Synergy DBL on 11/1/2018 6:35 PM
Bill Hawkins
Back in the dawn of time, DBL was limited to (if I remember correctly) named fields of no more than 256 characters.  So if you had an array of A30's the compiler would only let you define 8.  However, you could follow the array (named field) with an unnamed field and "continue" the array beyond 8 elements.

So you would do this
record
myArray ,8a30
              ,8a30

proc

myArray(10) = "hello world"

If you wanted to prevent this behavior, you had to define your arrays as "real arrays" using []..   Your example is just a variant of the "I'm allowed to subscript off the end of a field" behavior. 
Somebody from Synergy development may correct me on this, but I guess the underlying reason is that descriptors only a start position and type, but no length in their definition.  Adding bounds checking effectively turns every field into a real array, which provides the full scope for fields allowing validation.

Also in your example, you are sub-scripting out of the data division.  This too was possible (if not entirely intended) in DBL v2, so you could end up modifying the procedure division code with excessive subscripting.  I know of one enterprising soul who used this to modify the runtime behavior of their app.

Like a lot of things in Synergy, there's an arcane reason to allow things that do not seem to make sense in the modern development arena.

11/1/2018 10:50 PM   1  
Ace Olszowka
@Bill Hawkins

Thank you for that history! I really enjoy learning about the "why" something is done/allowed, it helps me better understand why things are the way they are (or why they could change today *grin*).

11/2/2018 1:20 PM   0  
Kish Baley
I knew you could end up modifying the procedural section by over-use of subscripting beyond the field, but I always assumed it was unintentional to do so. I can't believe someone would actually do this intentionally:
"I know of one enterprising soul who used this to modify the runtime behavior of their app"

That type of coding is a good way ensure job security since no one else would be able to make sense of your code ;-). Could be a "security" feature too, I guess.

11/9/2018 9:49 PM   0  
Please log in to comment on this idea.